native cmds and libs in the module library

[Chris Hegarty]

Alan, Mandy,

Thank you for your comments.

In short, I would like to integrate what is in the latest webrev (with 
your approval/review), and then continue the remainder of this work as a 
separate task.

Latest webrev
   http://cr.openjdk.java.net/~chegar/jigsaw/libbin_webrev.05/webrev/

Changes:
  - SimpleLibrary parent, natlib, natcmd, and config are now final
    (Mandys comment).
  - Cleanup some style issues.
  - Backout changes to Modules.gmk (install from jmod files).

Long description.

I think it best to postpone to the next phase of this work creating the 
images by installing from jmod files. The reason being that this doesn't 
work very well on Windows yet.

The jmod files for Windows contain both commands and libraries in the 
NATIVE_CMDS section of the jmod file, and config/property files in the 
NATIVE_LIBS section. It will not work to simply set --natcmd bin, and 
--natlib lib, as the findLocalNativeLibrary will then be searching in 
the wrong place.

The solution is to have the appropriate files put in the correct section 
of the jmod file in the first place, and this will require separating 
out commands, libraries, and config files during the build <sigh>. I 
think this is best done as a separate task.

Thanks,
-Chris.


On 24/01/2012 14:15, Alan Bateman wrote:
> ....
> Can you briefly summarize how one would use this on Windows? I assume it
> requires specifying the --natcmd and --natlib to be the same directory.
>
> In the simple library layout I added a flags word some time ago and it
> has many spare bits. Rather than storing 0 or 1 before each path then an
> alternative would be to use some of the spare bits.
>
> A minor nit but the code style with if-then-else is a bit inconsistent.
> SimpleLibrary.storePath, SimpleLibrary.resolveAndEnsurePath,
> Librarian.Create.go are just a couple of examples that jump out (there
> are many more).
>
> A general comment is that we'll need to go over this again once we get
> to clean-up the implementation, improve performance, make library
> operations atomic, etc. I mention this because what we have now is a bit
> inefficient and there's also quite a bit of hopping between new and old
> APIs. It will need a major clean-up at some point.
>
> On the tests then I think an important test to include is a test that
> attempts to install a library or binary outside of the bin and lib
> trees. I think the validation code that you've added will catch this but
> I think a test is important.
>
> -Alan.
>
>
>
>
>