Re: the ScriptingMojo

On Thu, Aug 27, 2020 at 3:34 AM Chapman Flack <chap(at)anastigmatix(dot)net> wrote:

> On 08/26/20 15:25, Chapman Flack wrote:
>
> > If the nar-maven-plugin is also generating such files when it uses MSVC
> > to build, then probably it also has some classes to help generating those
> > files (or it uses a dependency that has some classes to help generating
> > those files). It might not be too bad to end up adding that as a
> dependency
> > of the PGXS plugin (added by a profile conditioned on Windows os) in
> order
> > to reuse that part of its code, if it is accessible.
>
> That stuff seems to be here, and accessible:
>
>
> https://maven-nar.github.io/apidocs/com/github/maven_nar/cpptasks/ide/ProjectWriter.html
>
> ... but I have never really watched the nar-maven-plugin closely enough
> on Windows to see if it even creates such a file for pljava, or just passes
> everything on the command line. I don't know enough about MSVC to know if
> the project file is mandatory.
>
> In your commit cb0ceb9 I see that maybe you could get by with only the
> command line.
>
> Of course I would handle the /DNDEBUG, /DWindows, /DWIN32, and
> /DPLJAVA_SO_VERSION=1.6.0-SNAPSHOT by defines.add (without the /D)
> and overriding formatDefines to supply /D rather than -D. And really,
> the PLJAVA_SO_VERSION=project.version should be among the base defines
> supplied to any template.
>
> I would rather have the probing be done in the probe method; it could
> just have an OS name parameter and return a boolean.
>
> "Windows-MinGW-w64" : {
> probe : function(os) {
> return os.startsWith('Windows') && System.gete...GW64");
>
> "Windows-MSVC" : {
> probe : function(os) {
> return os.startsWith('Windows') && System.gete...VCINSTALLDIR");
>
> or something like that, where the outer container of the templates would
> be a [ ] rather than a { } so there would be a reliable order for probing
> the templates. The driving code could just go down the list calling
> probe(os) until one returned true, and use that one.
>
> Regards,
> -Chap
>

Yes, I am going to incorporate these changes in the configuration block. I
had hardcoded the values for the sake of getting a basic implementation
ready. A basic implementation is ready and now is working on for all
configurations except MinGW with a weird error
https://ci.appveyor.com/project/amCap1712/pljava/builds/34883248/job/0s01axnd9t76o6da
.

It seems there is some issue in linking but the logs do not hint this.
Another possible reason could be the packaging module not being able to
find the .dll. But again no sign of this from the logs. Do you have any
idea about what could be the issue here ?

Thanks
Regards,
Kartik