Re: Archives and/or Java
Sorry for the delay. Simon == Simon Richter [EMAIL PROTECTED] writes: [...] Simon The question is basically: Should jar files be treated Simon as libraries, losing the ability to stuff application Simon data into them, or should they be treated as Simon to-be-implemented archives, which can contain anything. Simon I'd vote for the latter choice, because it doesn't add Simon to the complexity of _LIBRARIES (which will eventually Simon be a good thing in light of the _LTLIBRARIES merge), Simon gives us an important feature (additional members in the Simon jar) without being an evil hack and also gives us the Simon archive feature (which isn't too important standalone). Eiter ways, even both together, sound fine to me. The former seems a lot simpler to implement (*), but if you are volunteering to implement the second... (*) I'm assuming _LIBRARIES and _LTLIBRARIES have been merged first. This shouldn't be too hard to do, and actually I'd like to do it, but it's unclear whether I'll have enought time to commit to this before before mid-march. [...] -- Alexandre Duret-Lutz
Re: Archives and/or Java
Simon == Simon Richter [EMAIL PROTECTED] writes: [...] (*) I'm assuming _LIBRARIES and _LTLIBRARIES have been merged first. Simon ... since jars would be an exception then, since they Simon are not built with libtool as all other libraries are. Sorry, the plan is *not* to always use Libtool! There will still be two kinds for libraries: `*.la' and `*.a'. The former should be built with libtool and the second without. The sole difference is that we decide what to do based on the suffix, rather than the _PRIMARY. This gives room for handling other suffixes. [...] -- Alexandre Duret-Lutz
Re: Archives and/or Java
Alexandre, On Tue, Feb 04, 2003 at 08:00:07PM +0100, Alexandre Duret-Lutz wrote: Simon == Simon Richter [EMAIL PROTECTED] writes: [Archives as directories] Simon ... Hrm, that would go in the direction of generic archive target Simon support, and one would have to think about files in subdirectories of Simon archives as well (propertiesdir = $(foo_jardir)/properties? Ick.). Ouch. Jup, my first thought as well, but I cannot think of a better solution currently. data_ARCHIVES = foo.tar.gz bar.zip baz.jar Automake can match suffixes like it does in _SOURCES to select a compiler. Sounds good. BTW, an item on the TODO list is to merge _LIBRARIES and _LTLIBRARIES. We can decide wether the user want to build a libtool library or a plain static library by looking at the suffix. Your $(propertiesdir) example apart, _ARCHIVES and _LIBRARIES do not look very different, do they? Indeed, but I think that subdirectories are a definite must for archives, while they would complicate building of libraries if they were handled similarly. While jar files are, technically speaking, libraries, they may also contain arbitrary files that are added to the interpreter's visible filespace; it would be difficult to express in which subdirectory such files should reside in (.class files are easy). The question is basically: Should jar files be treated as libraries, losing the ability to stuff application data into them, or should they be treated as to-be-implemented archives, which can contain anything. I'd vote for the latter choice, because it doesn't add to the complexity of _LIBRARIES (which will eventually be a good thing in light of the _LTLIBRARIES merge), gives us an important feature (additional members in the jar) without being an evil hack and also gives us the archive feature (which isn't too important standalone). Simon To do for archives: Files installed in archives need to Simon be installed at build time, I guess this is required to support things like $(propertiesdir). Is this still true if subdirectories are not used? (Like when we build _LIBRARIES.) Hrm, I believe there is no point in throwing _LIBRARIES and _ARCHIVES together. _LIBRARIES are built from _SOURCES, the intermediate objects are basically nameless (never mentioned in the Makefile.am). _ARCHIVES' members have names, and those are important at runtime, so there is no point in using _SOURCES; also they can be anything, from data over programs to other archives, so it makes sense IMO to allow the other primaries here (with some sanity checks -- there is no point in including _LTLIBRARIES or _PROGRAMS unless static). Simon -- GPG Fingerprint: 040E B5F7 84F1 4FBC CEAD ADC6 18A0 CC8D 5706 A4B4 msg06547/pgp0.pgp Description: PGP signature
Re: Archives and/or Java
Simon == Simon Richter [EMAIL PROTECTED] writes: [...] Simon Hrm, what if an archive would be treated like a directory, i.e. Simon foo_jar_DATA = foo.properties Sounds like a nice idea. Simon ... Hrm, that would go in the direction of generic archive target Simon support, and one would have to think about files in subdirectories of Simon archives as well (propertiesdir = $(foo_jardir)/properties? Ick.). Ouch. Simon Any ideas how we could implement this cleanly? Actually, though it looks Simon icky, the idea of making archives special directories has its Simon advantages. I could think of Simon data_TGZS = images.tgz Simon images_tgz_DATA = penguin.png windows.bmp Simon or even Simon data_ARCHIVES = images.archive [...] Maybe we don't need several primaries (_TGZS, _JAR, _ZIP, ...). How about data_ARCHIVES = foo.tar.gz bar.zip baz.jar Automake can match suffixes like it does in _SOURCES to select a compiler. BTW, an item on the TODO list is to merge _LIBRARIES and _LTLIBRARIES. We can decide wether the user want to build a libtool library or a plain static library by looking at the suffix. Your $(propertiesdir) example apart, _ARCHIVES and _LIBRARIES do not look very different, do they? Simon To do for archives: Files installed in archives need to Simon be installed at build time, I guess this is required to support things like $(propertiesdir). Is this still true if subdirectories are not used? (Like when we build _LIBRARIES.) Simon but I don't think that's a major issue Neither do I. AFAICT the major hindrance is the Automake guts. (Hopefully that's an occasion to do some cleaning.) [...skipping Java issues I can't comment on...] -- Alexandre Duret-Lutz
Archives and/or Java (was: Re: Java class files, again)
Eric, On Fri, Jan 31, 2003 at 11:19:29PM -0500, Eric Siegerman wrote: foo_jar_JAVA = Foo.java Don't forget that JARs can contain other things than .class files; it'd be nice if there was an automakish way to say include these other files too. Hrm, what if an archive would be treated like a directory, i.e. foo_jar_DATA = foo.properties ... Hrm, that would go in the direction of generic archive target support, and one would have to think about files in subdirectories of archives as well (propertiesdir = $(foo_jardir)/properties? Ick.). Any ideas how we could implement this cleanly? Actually, though it looks icky, the idea of making archives special directories has its advantages. I could think of data_TGZS = images.tgz images_tgz_DATA = penguin.png windows.bmp or even data_ARCHIVES = images.archive [...] for a platform dependent archive format (ZIP on Win32, tar.gz on Un*x). To do for archives: Files installed in archives need to be installed at build time, but I don't think that's a major issue -- simply make the install directory point at a temporary dir in the build tree and call the install targets for all directories below the archive we're currently building. Have I missed something? Hrm. Another major task in getting proper Java support done, but at least one can easily separate it out. cd .java/$* $(GCJ) -C `evil VPATH script here` Java requires a dependency model beyond what make can easily support: [...] - Java can easily have circular dependencies; they require all .java files in the circle to be compiled by the same compiler process Hrm, the quick and dirty solution would be to compile all .java files whose .class files are missing or out of date in one go, then sort out the classes using jv-scan. That would require jv-scan to be shipped with automake, I guess, and support for javac needs to be added (or are the names of inner classes standardized?). That should solve the circular dependency problem. For regular dependencies, we can look at the .class files, as they contain fully qualified names of all depended-on classes. Simon -- GPG Fingerprint: 040E B5F7 84F1 4FBC CEAD ADC6 18A0 CC8D 5706 A4B4 msg06516/pgp0.pgp Description: PGP signature
