Re: PL/Java new build plugin

From: Chapman Flack <chap(at)anastigmatix(dot)net>
To: Kartik Ohri <kartikohri13(at)gmail(dot)com>
Cc: pljava-dev(at)lists(dot)postgresql(dot)org
Subject: Re: PL/Java new build plugin
Date: 2020-07-21 03:25:17
Message-ID: 5F16601D.4080502@anastigmatix.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pljava-dev

On 07/20/20 23:00, Kartik Ohri wrote:
> On Tue, Jul 21, 2020 at 8:29 AM Kartik Ohri <kartikohri13(at)gmail(dot)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

In response to

Browse pljava-dev by date

  From Date Subject
Next Message Chapman Flack 2020-07-21 03:45:09 Re: PL/Java new build plugin
Previous Message Kartik Ohri 2020-07-21 03:00:57 Re: PL/Java new build plugin