Subject: Re: PL/Java new build plugin
To: Kartik Ohri <kartikohri13@gmail.com>
References: 
 <CAASLQ4Mva7dAXiS_c9OLhV4VzNHF=XNKJosuS5gtZTB6b4TW1Q@mail.gmail.com>
 <5F0E3972.5070609@anastigmatix.net> <5F0F2DA2.5090603@anastigmatix.net>
 <CAASLQ4N40xn-0S4Nsy0Ld75=Ny719MPUE7_aRP_5nAcAqkAqoQ@mail.gmail.com>
 <CAASLQ4OiWCQQwYFnxAQBe2dC6Ms803RjCMX-9AC2=1m0ZzeDhA@mail.gmail.com>
 <5F12FF49.6090906@anastigmatix.net> <5F12FF80.5020208@anastigmatix.net>
 <CAASLQ4MqSVnhK_GMgq03HcmOKk7a-v7b4L0yfPbtRO=mpqoQtA@mail.gmail.com>
 <5F1338F8.6030506@anastigmatix.net>
 <CAASLQ4OR8ZD4GRNHVGuTzJp_UP-PAcADxcz=uymiSFPpg8EEHQ@mail.gmail.com>
 <5F135B84.8070302@anastigmatix.net>
 <CAASLQ4O=tYGASWB6F+PTiB2L3RbmHcVX8XAbKHyhwBDOodH1zg@mail.gmail.com>
 <CAASLQ4P=c42e342-1YTTCBxA=CKBH2m=DLJN+ZQb5EJW6MyofQ@mail.gmail.com>
 <CAASLQ4NU3BgfCnVxvAbu9vK9+gtPT87xX1uBj57b0y2J6nxi+Q@mail.gmail.com>
 <5F14C34E.4020704@anastigmatix.net>
 <CAASLQ4PnDvNwJqMXALCbfAasFAXA6U_Yhf_uM6xAhx0XgyybpA@mail.gmail.com>
 <CAASLQ4MVCdq4j8oz4gEHue5XNurua=_PV0r7zFdM75L9bf3O=g@mail.gmail.com>
Cc: pljava-dev@lists.postgresql.org
From: Chapman Flack <chap@anastigmatix.net>
Message-ID: <5F16601D.4080502@anastigmatix.net>
Date: Mon, 20 Jul 2020 23:25:17 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.7.0
MIME-Version: 1.0
In-Reply-To: 
 <CAASLQ4MVCdq4j8oz4gEHue5XNurua=_PV0r7zFdM75L9bf3O=g@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 07/20/20 23:00, Kartik Ohri wrote:
> On Tue, Jul 21, 2020 at 8:29 AM Kartik Ohri <kartikohri13@gmail.com> wrote:
> 
>> Something isn't quite right about the handling of -Dpljava.libjvmdefault;
>>> the C compiler gives syntax errors if I use it (the build succeeds if
>>> I don't). Running with -X shows this being passed to the compiler:
>>>
>>> -DPLJAVA_LIBJVMDEFAULT=${pljava.qlibjvmdefault}
>>>
>> It is because the plugin is no longer detecting PLJAVA_LIBJVMDEFAULT. I
>> did not retain the method to automatically detect the variable and use it
>> and set its value. Should we keep it in the configuration block in pom.xml
>> since we have exposed the C quoting as well to the script engine or make an
>> exception for this to be specified via command line ?
>>
> To be sure and also to confirm, I didn't misunderstand something, can you
> share the configuration block and the maven command you executed ?

I didn't change the configuration block; my usual mvn command is like:

mvn -Duser.home=/var/tmp/nohome -Ppgjdbc-ng -Psaxon-examples -Pwnosign \
  -Dnar.cores=1 -Dso.debug=true \
  -Dpljava.libjvmdefault=/var/tmp/jdk-14+36/lib/server/libjvm.so \
  -Dpgsql.pgconfig=/var/tmp/nohome/pg$v/bin/pg_config clean install


The purpose is for -Dpgsql.pgconfig to be specified via command line;
it is there so that package maintainers (e.g. for Debian) can have it
built to refer to the default libjvm location on a deployed system
according to their packaging conventions. That doesn't have to be the
same as the jvm being used to build, so autodetecting wouldn't help.
It should be up to the package maintainer to choose what
-Dpljava.libjvmdefault path to give.

At present, how it gets from there to the compiler is Rube Goldberg;
the command line sets pljava.libjvmdefault, an antrun script checks if
that is non-null and defines a C-quoted version pljava.qlibjvmdefault,
and the haslibjvmdefault profile in pom.xml is activated if the first
property (without the q) exists, and when activated, it augments the
maven-nar-plugin configuration with a C compiler define for
PLJAVA_LIBJVMDEFAULT=${pljava.qlibjvmdefault}.

That could be a lot less circuitous once the nar plugin is out of the
picture, but for right now that's the way it works.

If the block of script had a test for the non-null system property
and set the 'q' property from it (like the last 8 lines of the old
antrun script), that at least would preserve the current behavior.

Regards,
-Chap