Re: Non-trivial example of Java & automake?
Mo> Paul, could you post a link to your project? I am going to be Mo> rewriting the build system for the tcljava project using automake, Mo> so I would also like to take a peek at some examples. I already Mo> have macros to do the JVM detection, I am just interested in the Mo> .java and .jar rules you use in your project. Java support in automake is still only so-so. Contributions and fixes welcome, of course... Tom
Re: Non-trivial example of Java & automake?
On Fri, 14 Jul 2000, Paul F. Kunz wrote: > > On Fri, 14 Jul 2000 17:35:27 -0400, Paul Berrevoets <[EMAIL PROTECTED]> said: > > > Does anyone know of a Java project that uses autoconf/automake that > > I could use as a template example for using autoconf/automake in our > > project? > >I asked the same question of myself several weeks ago and came up > blank. However, I managed to figure it out on my own with some hints > from Java based projects writing their own Makefiles. So I think the > answer to your question is my project. Paul, could you post a link to your project? I am going to be rewriting the build system for the tcljava project using automake, so I would also like to take a peek at some examples. I already have macros to do the JVM detection, I am just interested in the .java and .jar rules you use in your project. Mo DeJong Red Hat Inc
Re: Non-trivial example of Java & automake?
> On Fri, 14 Jul 2000 17:35:27 -0400, Paul Berrevoets <[EMAIL PROTECTED]> said: > Does anyone know of a Java project that uses autoconf/automake that > I could use as a template example for using autoconf/automake in our > project? I asked the same question of myself several weeks ago and came up blank. However, I managed to figure it out on my own with some hints from Java based projects writing their own Makefiles. So I think the answer to your question is my project.
Non-trivial example of Java & automake?
Does anyone know of a Java project that uses autoconf/automake that I could use as a template example for using autoconf/automake in our project? -- Thanks, Paul
Re: [Re: Shared library with source in sub directories]
Murray Cumming wrote: >> libfoo_la_LDADD = exceptions/libexceptions.la factories/libfactories.la <> libtool complains that the .la libraries are not libtool >> objects. Tom Tromey <[EMAIL PROTECTED]> > This seems like it should work. > Maybe it is a libtool problem of some kind? > I'd like to add an example of this working to the automake manual. Sorry, I meant that libfoo_la_LDADD = exceptions/libexceptions.a factories/libfactories.a doesn't work. Notice the .a instead of the .la. Apparently I should do with this with a noinst_LTLIBRARIES, so you do need to correct the bit in the automake manual that says that it isn't allowed. Murray Cumming [EMAIL PROTECTED] www.murrayc.com +44 7971 226563 Get free email and a permanent address at http://www.netaddress.com/?N=1
Re: [Re: Shared library with source in sub directories]
Murray> Apparently I should do with this with a noinst_LTLIBRARIES, so Murray> you do need to correct the bit in the automake manual that Murray> says that it isn't allowed. I think that has already been fixed. When I looked at my copy of the manual this morning it said that check_LTLIBRARIES is disallowed, but noinst_ is used for convenience libraries. Tom
Re: [Re: Shared library with source in sub directories]
Paul Berrevoets <[EMAIL PROTECTED]> wrote: > You create what are called 'convenience' libraries in libtool. > In exceptions/Makefile.am: > noinst_LTLIBRARIES = libexceptions.la > ... > Convenience libraries are not installed, and the object they contain will be > included in the higher level ltlibrary that LDADD's them. Thanks. I'll try this. I didn't do it before because the automake manual explicitly states that noinst_LTLIBRARIES is not allowed. I guess that's wrong. Murray Cumming [EMAIL PROTECTED] www.murrayc.com +44 7971 226563 Get free email and a permanent address at http://www.netaddress.com/?N=1
Re: Shared library with source in sub directories
Murray> libfoo_la_LDADD = exceptions/libexceptions.la factories/libfactories.la Murray> libtool complains that the .la libraries are not libtool Murray> objects. This seems like it should work. Maybe it is a libtool problem of some kind? I'd like to add an example of this working to the automake manual. Tom
Re: Shared library with source in sub directories
Murray Cumming wrote: > I'm trying to use automake/autoconf to build a shared library whose source > code is neatly organised sub directories (about 5 levels wide and 5 levels > deep). > > If this was an application then I would build static libraries in each of the > subfolders and link them all together at the top. But when I do something like > this: > > libfoo_la_LDADD = exceptions/libexceptions.la factories/libfactories.la > > libtool complains that the .la libraries are not libtool objects. I could > build libtool libraries in the sub directories instead of static libraries, > but then I'd have to install each of those temporary libraries. That would be > stupid. > > So, how should I use automake to build a shared library if the source is in > sub directories? You create what are called 'convenience' libraries in libtool. In exceptions/Makefile.am: noinst_LTLIBRARIES = libexceptions.la ... Convenience libraries are not installed, and the object they contain will be included in the higher level ltlibrary that LDADD's them. -- Paul
Shared library with source in sub directories
I'm trying to use automake/autoconf to build a shared library whose source code is neatly organised sub directories (about 5 levels wide and 5 levels deep). If this was an application then I would build static libraries in each of the subfolders and link them all together at the top. But when I do something like this: libfoo_la_LDADD = exceptions/libexceptions.la factories/libfactories.la libtool complains that the .la libraries are not libtool objects. I could build libtool libraries in the sub directories instead of static libraries, but then I'd have to install each of those temporary libraries. That would be stupid. So, how should I use automake to build a shared library if the source is in sub directories? Murray Cumming [EMAIL PROTECTED] www.murrayc.com +44 7971 226563 Get free email and a permanent address at http://www.netaddress.com/?N=1
Re: automake include files?
Tom Tromey wrote: > > Dean> I am looking for a way to include extra rules in every > Dean> Makefile.in that automake generates. > [..] > Dean> %.s: %.c > > Note that "%" rules are not portable. > I wonder if automake should warn about this. I am wondering if it would be possible to extend automake to expand rules like these into something portable. This kind of %-rules or even more unportable gmake-rules are quite handy for packages which are not supposed to be portable, but apply and rely on the combination of gmake and automake. This is not quite conforming to automake's principles, nevertheless is rather powerful combination and works with automake for many cases. Ralf -- Ralf Corsepius Forschungsinstitut fuer Anwendungsorientierte Wissensverarbeitung (FAW) Helmholtzstr. 16, 89081 Ulm, Germany Tel: +49/731/501-8690 mailto:[EMAIL PROTECTED] FAX: +49/731/501-999 http://www.faw.uni-ulm.de
pattern rules (was Re: automake include files? )
Tom Tromey writes: > Dean> I am looking for a way to include extra rules in every > Dean> Makefile.in that automake generates. > > The typical way is to make a "Makefile.include" and then include it > from each Makefile.am. > > Dean> %.s: %.c > > Note that "%" rules are not portable. > I wonder if automake should warn about this. > > Tom After doing my recent suffix rule changes (AFAIK not applied yet) I think that some form of limited pattern->suffix rule mapping is possible for pattern rules with leading %'s and only one % on the RHS. I think this type of "simple" pattern rule makes up a large part of pattern rule usage. i.e. they are being used because they are easier to write/understand, not to get the extra functionality. This mapping could be activated by an automake option --expand-pattern-rules so as not to surprise maintainers currently using "non-simple" pattern rules. e.g. %_c.h %_s.h %_c.c %_s.c : %.idl $(idlcomp) $< expands to: .idl_c.h: $(serialize) $(idlcomp) $< .idl_s.h: $(serialize) $(idlcomp) $< .idl_c.c: $(serialize) $(idlcomp) $< .idl_s.c: $(serialize) $(idlcomp) $< If people are interested I could include this in the next version of my built source patch, as I'm already doing something similar by hand. In fact it's rather tedious and difficult by hand (lot of cutting and pasting) so automating it might be quite a win. The serialize is to prevent parallel builds double generating files and getting them mangled. The main difficult is coming up with a portable version of serialize written only in shell script :) Alex.
