automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Archives and/or Java (was: Re: Java class files, again)


From: Simon Richter
Subject: Archives and/or Java (was: Re: Java class files, again)
Date: Sat, 1 Feb 2003 13:40:12 +0100
User-agent: Mutt/1.5.3i

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

Attachment: pgpklx32ArSFg.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]