[Scons-users] problem with new Jar builder-wrapper in 3.0.1

[Mats Wichmann]

On 11/18/2017 01:05 AM, Daniel Moody wrote:
> Hey Mats,
> 
> I just joined the users mailing list, and recreated the email from the link
> (https://pairlist4.pair.net/pipermail/scons-users/2017-November/006469.html),
> so sorry if the formatting gets messed up.
> 
> Regarding this issue, the Jar builder does not handle embedded lists. I saw
> you created a flat list and still the manifest did not work correctly.

non-flat lists were our problem. there was a prospect of having three
instances, but two had already been changed, leaving the older code
commented out, probably due to problems with including the manifest. I
actually toyed with using Flatten() in our code to make the fix explicit
for future developers. I may go back to that, though if scons is going
to accept it, maybe I don't need to - needing a flat list is fine as
long as it's documented :)

> I tried to recreate your issue with the flat source list and manifest
> source but I could not. I created a test which I thought was similar to
> what you are doing in your build here:
> https://github.com/SConsProject/scons/pull/18/commits/e474eb4e85d18fe56df4bbbdc180df951fbb20f0
> 
> And seems to be working with changes I submitted to the jar.py tool.
> 
> Let me know if you have any ideas on how I can write a test that can
> reproduce your issue, or if these changes fix it. :)

So to be clear, if a manifest is not specified, jar creates one.  So our
builds do end up with a manifest file, just not the one we wanted to put
there. From just glancing at it, your test looks like it will check for
that case, since it looks for specific contents. In our instance, we
tried to supply:

===
Manifest-Version: 1.0
Class-Path: iotivity.jar
Created-By: 1.8.0_151 (Oracle Corporation)
Main-Class: org.iotivity.base.examples.SimpleServer
===

but the "default" one that ends up in the jarfile looks like:

===
Manifest-Version: 1.0
Created-By: 1.8.0_151 (Oracle Corporation)
===

It was only adding debug prints to jar.py that showed me it wasn't
actually recognizing a manifest file in the source list and to try
something different - if I turn it into a node via File('MANIFEST.MF')
it's picked up fine by that part of the code, but otherwise it fails all
of the checks and is discarded.

If I'd been a little more awake I would have just grokked it from the
output line from building, which of course now is quite clear:

jar cf
out/linux/x86_64/debug/java/examples-java/simpleserver/simpleserver.jar
-C out/linux/x86_64/debug/java/examples-java/simpleserver/classes ...

as opposed to a working:

jar cfm
out/linux/x86_64/debug/java/examples-java/simpleserver/simpleserver.jar
java/examples-java/simpleserver/MANIFEST.MF -C
out/linux/x86_64/debug/java/examples-java/simpleserver/classes ...

no 'm' flag, no manifest file.

I'm still not 100% clear why it is not being grokked as a manifest but
as I said, I think it's variant-dir stuff.  With debug on a failing case:

XXX found non-node path: MANIFEST.MF
XXX we are in:
/home/mats/iotivity.work/out/linux/x86_64/debug/java/examples-java/simpleclientserver

Namely it's going to do os.path.isfile() in a place where Python doesn't
see any files, only SCons sees them there through mirroring.