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

[Bill Deegan]

Is your MANIFEST.MF a generated file (created by some other SCons logic),
or a regular file that exists before SCons is run?

On Sat, Nov 18, 2017 at 10:31 AM, Mats Wichmann <mats at wichmann.us> wrote:

> 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.
>
> _______________________________________________
> Scons-users mailing list
> Scons-users at scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20171118/6269e52a/attachment.html>