Re: include Makefile.extra
Understood. Thank you tip me the key!
On Fri, Apr 06, 2001 at 02:01:49AM -0300, Alexandre Oliva wrote:
> On Apr 6, 2001, Reed Lai <[EMAIL PROTECTED]> wrote:
>
> > I cannot include an extra makefile in Makefile.am, because the
> > automake will error since that extra makefile is created by
> > configure and not exist when automake is running.
>
> Then you should probably arrange for autoconf to expand the file into
> the generated Makefile. See AC_SUBST_FILE.
>
> --
> Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
> Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
> CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
> Free Software Evangelist*Please* write to mailing lists, not to me
--
Reed Lai http://w3.icpdas.com/reed/ | ICPDAS http://www.icpdas.com
GnuPG (DSA/ElGamal) 0x7199EAD3 Reed Lai (key #1) <[EMAIL PROTECTED]>
KeyServer: search.keyserver.net | HAM: BV4QO | NIC-handle: RL7000
Re: include Makefile.extra
On Apr 6, 2001, Reed Lai <[EMAIL PROTECTED]> wrote:
> I cannot include an extra makefile in Makefile.am, because the
> automake will error since that extra makefile is created by
> configure and not exist when automake is running.
Then you should probably arrange for autoconf to expand the file into
the generated Makefile. See AC_SUBST_FILE.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
include Makefile.extra
Seniors, I use both of autoconf and automake to maintain my project. I cannot include an extra makefile in Makefile.am, because the automake will error since that extra makefile is created by configure and not exist when automake is running. How do I deal with this requirement automatically without manually add the extra Makefile to Mailfile.in? Please help! Thanks -- Reed Lai
Re: CVS autoconf + CVS automake = autoconf doesn't know its version
On Apr 6, 2001, Raja R Harinath <[EMAIL PROTECTED]> wrote:
> Hi,
> Alexandre Oliva <[EMAIL PROTECTED]> writes:
>> On Apr 5, 2001, Raja R Harinath <[EMAIL PROTECTED]> wrote:
>> > The problem is that 'automake' now depends on the AC_SUBSTs in
>> > AM_INIT_AUTOMAKE to subst in VERSION and PACKAGE. Since the same
>> > 'automake' doesn't understand 'm4_include's, it does not see the
>> > actual definition of AM_INIT_AUTOMAKE (autoconf bypasses the 'aclocal'
>> > mechanism). Here's a patch to autoconf to fix this.
>>
>> I'm afraid patching aclocal.m4 won't help much, since it's a
>> generated file.
> Not in 'autoconf'. As I said, autoconf bypasses 'aclocal'.
Oh! That shows how out-dated I am in terms of autoconf development
:-(
Under this new light, I agree your patch is ok.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: SGI mode depcomp breaks when '.' appears in source filenames twice
Hi, Alexandre Oliva <[EMAIL PROTECTED]> writes: > On Apr 5, 2001, Raja R Harinath <[EMAIL PROTECTED]> wrote: > > Robert Boehne <[EMAIL PROTECTED]> writes: > >> sed 's/^[^\.]*\.o://' | tr ' > > > Try changing that to > > > sed 's/^.*\.o://' | tr ' > > > This should be safe. I don't see why the original tried to avoid > > '.'s. The regexp is limited to the first ':' -- so the '.*' cannot > > swallow any more of the line. > > Perhaps `[^:]*', just to be on the safe side? Well -- the whole idea is to remove the rule targets. I know of only one use of multiple colons on a line -- in GNU make. Even there, everything before a ':' is a rule target. My comment "limited to the first ':'" may not be accurate, but I don't see any advantage to not always removing everything before a ':'. - Hari -- Raja R Harinath -- [EMAIL PROTECTED] "When all else fails, read the instructions." -- Cahn's Axiom "Our policy is, when in doubt, do the right thing." -- Roy L Ash
Re: CVS autoconf + CVS automake = autoconf doesn't know its version
Hi, Alexandre Oliva <[EMAIL PROTECTED]> writes: > On Apr 5, 2001, Raja R Harinath <[EMAIL PROTECTED]> wrote: > > The problem is that 'automake' now depends on the AC_SUBSTs in > > AM_INIT_AUTOMAKE to subst in VERSION and PACKAGE. Since the same > > 'automake' doesn't understand 'm4_include's, it does not see the > > actual definition of AM_INIT_AUTOMAKE (autoconf bypasses the 'aclocal' > > mechanism). Here's a patch to autoconf to fix this. > > I'm afraid patching aclocal.m4 won't help much, since it's a > generated file. Not in 'autoconf'. As I said, autoconf bypasses 'aclocal'. - Hari -- Raja R Harinath -- [EMAIL PROTECTED] "When all else fails, read the instructions." -- Cahn's Axiom "Our policy is, when in doubt, do the right thing." -- Roy L Ash
Re: SGI mode depcomp breaks when '.' appears in source filenames twice
On Apr 5, 2001, Raja R Harinath <[EMAIL PROTECTED]> wrote:
> Robert Boehne <[EMAIL PROTECTED]> writes:
>> sed 's/^[^\.]*\.o://' | tr '
> Try changing that to
> sed 's/^.*\.o://' | tr '
> This should be safe. I don't see why the original tried to avoid
> '.'s. The regexp is limited to the first ':' -- so the '.*' cannot
> swallow any more of the line.
Perhaps `[^:]*', just to be on the safe side?
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: CVS autoconf + CVS automake = autoconf doesn't know its version
On Apr 5, 2001, Raja R Harinath <[EMAIL PROTECTED]> wrote:
> The problem is that 'automake' now depends on the AC_SUBSTs in
> AM_INIT_AUTOMAKE to subst in VERSION and PACKAGE. Since the same
> 'automake' doesn't understand 'm4_include's, it does not see the
> actual definition of AM_INIT_AUTOMAKE (autoconf bypasses the 'aclocal'
> mechanism). Here's a patch to autoconf to fix this.
I'm afraid patching aclocal.m4 won't help much, since it's a generated
file.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Re: Including foreign makefiles
On Apr 5, 2001, Adam C Powell IV <[EMAIL PROTECTED]> wrote:
> By the way, how do I unsubscribe?
See the `List-Unsubscribe' header in every message you receive.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
nearly there... yet another question first
in one of the leaf Makefile.am's I tried libexec_PROGRAMS = smb_auth smb_auth_CFLAGS += -DSAMBAPREFIX=\"/usr/local/samba\" -DHELPERSCRIPT=\"test.sh\" (hoping that the goatbook comment re: automake 1.5 in the FAQ was based on current CVS code :]) Now automake --foreign in the root of the source tree (uhmm,thats ../../../../../ ) complains about a missing compile script. --add-missing installs compile in the leaf branch. Commenting out the _CFLAGS line removes the complaint. Why doesn't it install compile in the top_srcdir? Is the relationship between compile and using _CFLAGS a guaranteed thing, or is there something elsewhere in the project (configure.in etc ) that could remove the need for compile? Rob
Re: make dist and BUILT_SOURCES
- Original Message - From: "Tom Tromey" <[EMAIL PROTECTED]> To: "Robert Collins" <[EMAIL PROTECTED]> Cc: "Akim Demaille" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Friday, April 06, 2001 9:43 AM Subject: Re: make dist and BUILT_SOURCES > > "Robert" == Robert Collins <[EMAIL PROTECTED]> writes: > > >> BUILT_SOURCES aren't automatically distributed. > > Robert> Well... it was trying to :]. I've sent in an extract from > Robert> Makefile.am,, would you like a test case? > > Sure. > > Were they also listed in another foo_SOURCES variable? > That would cause them to end up in the dist. Yes they were. I didn't know you could do BUILT_foo_SOURCES. I'll try rearranging the targets like that and get back to you.. Rob
Re: make dist and BUILT_SOURCES
> "Robert" == Robert Collins <[EMAIL PROTECTED]> writes: >> BUILT_SOURCES aren't automatically distributed. Robert> Well... it was trying to :]. I've sent in an extract from Robert> Makefile.am,, would you like a test case? Sure. Were they also listed in another foo_SOURCES variable? That would cause them to end up in the dist. Robert> bin_PROGRAMS = foo Robert> foo_SOURCES = sources to be dist Robert> nodist_foo_SOURCES = I think you can guess Yes, this should work. Tom
Re: SGI mode depcomp breaks when '.' appears in source filenames twice
Robert Boehne <[EMAIL PROTECTED]> writes: > I've been having some problems with depencency tracking under > IRIX with the native compiler, it didn't help to use GNU sed, > so I tracked the problem down to this line from depcomp: > > sed 's/^[^\.]*\.o://' | tr ' Try changing that to sed 's/^.*\.o://' | tr ' This should be safe. I don't see why the original tried to avoid '.'s. The regexp is limited to the first ':' -- so the '.*' cannot swallow any more of the line. - Hari -- Raja R Harinath -- [EMAIL PROTECTED] "When all else fails, read the instructions." -- Cahn's Axiom "Our policy is, when in doubt, do the right thing." -- Roy L Ash
SGI mode depcomp breaks when '.' appears in source filenames twice
Automake: I've been having some problems with depencency tracking under IRIX with the native compiler, it didn't help to use GNU sed, so I tracked the problem down to this line from depcomp: sed 's/^[^\.]*\.o://' | tr ' ... For a source file named ExprIntrp.tab.c, the dependency file produced has this for it's contents: ExprIntrp.tab.lo : \ ExprIntrp.tab.o: /usr/include/stdio.h /usr/include/standards.h /usr/include/sgidefs.h /usr/include/alloca.h #:fec /usr/include/stdio.h : /usr/include/standards.h : /usr/include/sgidefs.h : /usr/include/alloca.h : #:fec : The problem is the appearance of 'ExprIntrp.tab.o:' on the second line, this is intended to be stripped out, and is if the sed command from depcomp is altered to sed 's/^[^\.]*\.tab.o://' But that, of course, is not the fix. Could a sed guru suggest a fix for this particular problem? Thanks, Robert -- Robert Boehne Software Engineer Ricardo Software Chicago Technical Center TEL: (630)789-0003 x. 238 FAX: (630)789-0127 email: [EMAIL PROTECTED]
CVS autoconf + CVS automake = autoconf doesn't know its version
Hi, The following patch fixes a problem with CVS autoconf, if a recent enough CVS snapshot of automake was used on it. The problem is that 'automake' now depends on the AC_SUBSTs in AM_INIT_AUTOMAKE to subst in VERSION and PACKAGE. Since the same 'automake' doesn't understand 'm4_include's, it does not see the actual definition of AM_INIT_AUTOMAKE (autoconf bypasses the 'aclocal' mechanism). Here's a patch to autoconf to fix this. Index: aclocal.m4 === RCS file: /cvs/autoconf/aclocal.m4,v retrieving revision 1.9 diff -u -p -u -r1.9 aclocal.m4 --- aclocal.m4 2000/05/24 13:00:34 1.9 +++ aclocal.m4 2001/04/05 22:35:48 @@ -3,3 +3,11 @@ m4_include([m4/missing.m4]) m4_include([m4/sanity.m4]) m4_include([m4/atconfig.m4]) m4_include([m4/m4.m4]) + +# Most versions of 'automake' subst these in when 'AM_INIT_AUTOMAKE' +# is present in configure.in. However, some versions don't -- they +# depend on the fact that aclocal.m4 will have lines that subst them in. +# Some of those versions also don't understand 'm4_include'. +# Help them along. +AC_SUBST(PACKAGE) +AC_SUBST(VERSION) - Hari -- Raja R Harinath -- [EMAIL PROTECTED] "When all else fails, read the instructions." -- Cahn's Axiom "Our policy is, when in doubt, do the right thing." -- Roy L Ash
Patch: make dist in subdirs before handling the current directory
Changelog: * distdir.am: Recurse into subdirs before handling files in the current directory. This patch reverses the order of subdir processing with current directory files for the make dist target. This should allow make dist with _SOURCES targets like foo/a.c or foo/bar/a.c. It' won't help with _SOURCES targets like ../foo/bar/a.c where ../foo/bar is created by the Makfile in ../foo and that hasn't been called yet. A possible solution for that would be to call those makefiles? Also attached is an updated test - my previous test was for subdir sources with only one Makefile, which still fails because the subdir isn't created. Rob distdirsubdir.patch subobj5.test
Re: 2nd possibly silly question: XTRA_foo_SOURCES
- Original Message - From: "Tom Tromey" <[EMAIL PROTECTED]> To: "Robert Collins" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Friday, April 06, 2001 3:25 AM Subject: Re: 2nd possibly silly question: XTRA_foo_SOURCES > > "Robert" == Robert Collins <[EMAIL PROTECTED]> writes: > > Robert> squid_SOURCES = \ > Robert> access_log.c acl.c asn.c auth_modules.c authenticate.c cache_cf.c > Robert> cf_parser.h \ > Robert> disk.c @DNS_SOURCE@ errorpage.c > > You can't use a configure substitution in a _SOURCES variable. > This is a very common mistake :-( > > One workaround would be to use automake conditionals instead of > configure substitutions. > > Tom > I'm now using conditionals. And I have a Makefile > 6000 lines lone (170Kb). (I'm not whining about that in this email :} as I understand a fix is in the pipeline.) [and I understand pipelines :] I'm throwing peanuts from the gallery here (and I know that I'm doing that :]). 1) The http://www.gnu.org/manual/automake/html_mono/automake.html documentation implies that _SOURCES can take the same style of late bound entries as _PROGRAMS and _LIBRARIES can, as long as EXTRA_foo_SOURCES contains all possible entries. - This probably leads to the common mistake. (relevant quote: Automake must know all the source files that could possibly go into a program, even if not all the files are built in every circumstance. Any files which are only conditionally built should be listed in the appropriate `EXTRA_' variable. For instance, if `hello-linux.c' were conditionally included in hello, the `Makefile.am' would contain: EXTRA_hello_SOURCES = hello-linux.c Similarly, sometimes it is useful to determine the programs that are to be built at configure time. For instance, GNU cpio only builds mt and rmt under special circumstances. In this case, you must notify automake of all the programs that can possibly be built, but at the same time cause the generated `Makefile.in' to use the programs specified by configure. This is done by having configure substitute values into each `_PROGRAMS' definition, while listing all optionally built programs in EXTRA_PROGRAMS. ) 2) I don't understand why there is a fundamental difference between _PROGRAMS (allows configure substitutions both directly and indirectly ($(CONFGSUBSTVAR)) and _SOURCES wihch doesn't. - Working on the principle of least surprise, this fails :]. Rob
Re: program target missing $(EXEEXT)
- Original Message - From: "Akim Demaille" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: "Robert Collins" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Friday, April 06, 2001 3:43 AM Subject: Re: program target missing $(EXEEXT) > > "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes: > > Tom> I think the program rules somehow touched both PROG and PROG.exe. > > Sorry, I'm lost :( What do you mean? > > I'm risking an answer which might be completely irrelevant: we now > always use $(EXEEX), hence we don't to address both PROG and PROG.exe: > just PROG$(EXEEXT). > Uhmm, actually it would be good to have a dummy PROG that just depends on PROG$(EXEEXT) Why? Cygwin again :] make prog will build the target prog, not prog.exe, and will build that via implicit rules. This is a nice-to-have BTW. Rob
Re: make dist and BUILT_SOURCES
- Original Message - From: "Tom Tromey" <[EMAIL PROTECTED]> To: "Akim Demaille" <[EMAIL PROTECTED]> Cc: "Robert Collins" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Friday, April 06, 2001 3:13 AM Subject: Re: make dist and BUILT_SOURCES > > "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes: > > Robert> is there some way to exclude specific built sources from the > Robert> disrtribution? > > Akim> Automake will always ship parsers and scanners, but I don't > Akim> believe it ships all the BUILT_SOURCES. > > BUILT_SOURCES aren't automatically distributed. Well... it was trying to :]. I've sent in an extract from Makefile.am,, would you like a test case? > With the cvs automake you have a lot more control over what is > distributed than you used to. Unfortunately this isn't documented :-( > > You can do something like this: > > bin_PROGRAMS = foo > dist_foo_SOURCES = sources for foo that should dist > nodist_foo_SOURCES = sources for foo that shouldn't dist > > If you leave off dist/nodist then you get whatever the default is for > the particular variable (it depends on the variable, for backwards > compatibility). can I do bin_PROGRAMS = foo foo_SOURCES = sources to be dist nodist_foo_SOURCES = I think you can guess Instead? Regardless the problem should be solved - thanks. Rob > > Tom >
Re: Including foreign makefiles
By the way, how do I unsubscribe? http://mail.gnu.org/mailman/listinfo/automake has no such instructions, nor was there anything useful in the subscribe confirmation email or other emails from the list. Thanks, -Adam P. GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe!
Re: Including foreign makefiles
Adam C Powell IV wrote: > I think the following options are available to me: > >* hard-code the variable I had hoped to get from the foreign makefile, which will >break > if it differs from platform to platform or machine to machine. >* give up on cross-platform and hand-create .la files for the Debian packages of >the > foreign libs (I maintain that package), which will only allow linking against >the > Debian-packaged version of the toolkit. I think I'm going to go with option 1. The PETSc libs will be linked just fine, but other system libs from MPI to BLAS are a total crap-shoot without the ability to import the variable from an included makefile. So much for cross-platform. Leaving the list now, so please CC any replies to me. Thanks for all the help. -Adam P. GPG fingerprint: D54D 1AEE B11C CE9B A02B C5DD 526F 01E8 564E E4B6 Welcome to the best software in the world today cafe!
Re: program target missing $(EXEEXT)
> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes: Tom> I think the program rules somehow touched both PROG and PROG.exe. Sorry, I'm lost :( What do you mean? I'm risking an answer which might be completely irrelevant: we now always use $(EXEEX), hence we don't to address both PROG and PROG.exe: just PROG$(EXEEXT).
Re: program target missing $(EXEEXT)
Tom> I'm suprised by that. I thought we were always building as Tom> foo.$(EXEEXT). That's why we did the ugly _PROGRAMS rewrite Tom> stuff in am_install_var. Akim> As a matter of fact we do rewrite *_PROGRAMS, but *after* having Akim> set @result which is the return value of am_install_vars. Akim> Therefore the file_contents maps %PROGRAM% to what the user has Akim> written. I think the program rules somehow touched both PROG and PROG.exe. Tom
Re: program target missing $(EXEEXT)
> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes: Akim> Sorry, I think I was confused. I checked, and it seems to be Akim> what was designed: compile as foo, but *install* as Akim> foo.$(EXEEXT). I might be wrong again, but at least 1.4 behaves Akim> this way. Tom> I'm suprised by that. I thought we were always building as Tom> foo.$(EXEEXT). That's why we did the ugly _PROGRAMS rewrite Tom> stuff in am_install_var. Errr, maybe my answer is completely out of topic... A bug was found: $(EXEEXT) missing in programs.am, and I was answering to the question `I'm surprised we need $(EXEEXT) in programs.am' (which is a very natural question).
Re: program target missing $(EXEEXT)
> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes: Robert> AC_EXEEXT was already present. I added AC_OBJEXT and ran Robert> automake --foreign again, no change. Akim> Sorry, I think I was confused. I checked, and it seems to be Akim> what was designed: compile as foo, but *install* as Akim> foo.$(EXEEXT). I might be wrong again, but at least 1.4 behaves Akim> this way. Tom> I'm suprised by that. I thought we were always building as Tom> foo.$(EXEEXT). That's why we did the ugly _PROGRAMS rewrite Tom> stuff in am_install_var. As a matter of fact we do rewrite *_PROGRAMS, but *after* having set @result which is the return value of am_install_vars. Therefore the file_contents maps %PROGRAM% to what the user has written. It shouldn't be any problem until someone has the good idea to use $(EXEEXT) to define *_PROGRAMS... I'd be happy to clean this, but there is already quite a few patches in the queue :( TODO?
Re: program target missing $(EXEEXT)
Robert> AC_EXEEXT was already present. I added AC_OBJEXT and ran Robert> automake --foreign again, no change. Akim> Sorry, I think I was confused. I checked, and it seems to be Akim> what was designed: compile as foo, but *install* as Akim> foo.$(EXEEXT). I might be wrong again, but at least 1.4 behaves Akim> this way. I'm suprised by that. I thought we were always building as foo.$(EXEEXT). That's why we did the ugly _PROGRAMS rewrite stuff in am_install_var. Tom
RE: -Wp flag??
Thanks!!! I was using automake 1.4, and that was the problem.. -Original Message- From: Tom Tromey [mailto:[EMAIL PROTECTED]] Sent: 5 avril, 2001 13:09 To: [EMAIL PROTECTED] Cc: Paul Wighton; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: -Wp flag?? > "Gary" == Gary V Vaughan <[EMAIL PROTECTED]> writes: Gary> I'm leaving the text of your email intact for the benefit of new Gary> readers on [EMAIL PROTECTED] It appears that the problems you Gary> are experiencing are caused by the automated compiler dependency Gary> generation code in automake. Paul, you don't say what version of automake you are using. If you are using 1.4 then the problem is that that version requires GNU make and gcc when dependency tracking is enabled. The fix is to disable dependency tracking. Tom
Re: 2nd possibly silly question: XTRA_foo_SOURCES
> "Robert" == Robert Collins <[EMAIL PROTECTED]> writes: Robert> squid_SOURCES = \ Robert> access_log.c acl.c asn.c auth_modules.c authenticate.c cache_cf.c Robert> cf_parser.h \ Robert> disk.c @DNS_SOURCE@ errorpage.c You can't use a configure substitution in a _SOURCES variable. This is a very common mistake :-( One workaround would be to use automake conditionals instead of configure substitutions. Tom
Re: Multiple lexers and $derived_LFLAGS
> "Esben" == Esben Haabendal Soerensen <[EMAIL PROTECTED]> writes: Esben> The automake docs claims that the ylwrap script solves the Esben> problem with including multiple yacc or lex source fles in a Esben> single program, but it seem to only solve a very small part of Esben> the problem. That's right. For the rest of the method you have to do what it says in the `Yacc and Lex' node in the automake manual. Tom
Re: make dist and sources in subdirs
> "Robert" == Robert Collins <[EMAIL PROTECTED]> writes: Robert> However there is still a problem: Robert> make dist doesn't create directory foo. This is a bug. >> 2) Do the stub directories such as foo, which only have 2 or three c >> files need Makefile.am's ? Robert> I take it the answer to this is "yes it solves creating the Robert> directory?" The reason why I was hoping to avoid a Makefile Robert> is that it saves a level of recursion during make, and on Robert> cygwin that saves time . Adding a new Makefile.am is a workaround. However in your particular case I think `make dist' should work without the Makefile.am. Tom
Re: make dist and sources in subdirs
Alexandre> There's an automake option that tells it to keep object Alexandre> files in subdirs. I don't recall the exact spelling. Akim> Couldn't find it in the doc (probably still too experimental?), Akim> but a RTFC shows it's subdir-objects. See the subobj*.test Akim> files. That's a generous interpretation! Really it is just that the docs suck. I've been lame about keeping them up-to-date. subdir-objects ought to be documented. Tom
Re: make dist and BUILT_SOURCES
> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes: Robert> is there some way to exclude specific built sources from the Robert> disrtribution? Akim> Automake will always ship parsers and scanners, but I don't Akim> believe it ships all the BUILT_SOURCES. BUILT_SOURCES aren't automatically distributed. With the cvs automake you have a lot more control over what is distributed than you used to. Unfortunately this isn't documented :-( You can do something like this: bin_PROGRAMS = foo dist_foo_SOURCES = sources for foo that should dist nodist_foo_SOURCES = sources for foo that shouldn't dist If you leave off dist/nodist then you get whatever the default is for the particular variable (it depends on the variable, for backwards compatibility). Tom
Re: -Wp flag??
> "Gary" == Gary V Vaughan <[EMAIL PROTECTED]> writes: Gary> I'm leaving the text of your email intact for the benefit of new Gary> readers on [EMAIL PROTECTED] It appears that the problems you Gary> are experiencing are caused by the automated compiler dependency Gary> generation code in automake. Paul, you don't say what version of automake you are using. If you are using 1.4 then the problem is that that version requires GNU make and gcc when dependency tracking is enabled. The fix is to disable dependency tracking. Tom
Re: depcomp bug (was [Fwd: CVS update: ccvs])
> "Derek" == Derek R Price <[EMAIL PROTECTED]> writes: Derek> One of the other CVS developers reported a bug in depcomp on Derek> BSD/OS. Apparently the included /bin/sh doesn't set $? inside Derek> of the conditional. His original message and fix are attached. Thanks. This looks good to me. I'll check it in when I get a chance (unless someone beats me to it). Tom
Re: Errors during autoamake
> "Naveen" == Naveen Chandra <[EMAIL PROTECTED]> writes: Naveen> I am using gnu tools to configure my build environment. If I run Naveen> automake --foreign --include-deps I get an error Naveen> "automake: no `Makefile.am' found or specified" eventhough I have Naveen> Makefile.am. I have looked at automake doc but did'nt got any macro to Naveen> set the path for Makefile.am Naveen> What is the solution for this problem.? Do you not have AC_OUTPUT(Makefile) in configure.in? That is the most likely problem. Tom
depcomp bug (was [Fwd: CVS update: ccvs])
Hey folks! One of the other CVS developers reported a bug in depcomp on BSD/OS. Apparently the included /bin/sh doesn't set $? inside of the conditional. His original message and fix are attached. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] CollabNet ( http://collab.net ) -- Boy: A noise with dirt on it Derek R. Price writes: > > * depcomp: Don't count on $? being set in then or else clauses. > > What system is this happening on? depcomp is part of the Automake > distribution. Boy, that was fast! I was going to send you a message suggesting that you pass that change on to the Automake folks, but you beat me to it. It happens on my BSD/OS system with bin/sh (but not with bash or ksh). Looking at the SUS-2 specs for sh: http://www.opengroup.org/onlinepubs/7908799/xcu/chap2.html I don't see any requirement that the exit status of the conditional be available in $? in the then and else clauses and given one counter example and the fact that it's easy enough to work around, it seems like the prudent thing to do. -Larry Jones He's just jealous because I accomplish so much more than he does. -- Calvin Index: depcomp === RCS file: /home2/cvsroot/ccvs/depcomp,v retrieving revision 1.1 retrieving revision 1.2 diff -u -r1.1 -r1.2 --- depcomp 2000/12/21 22:14:19 1.1 +++ depcomp 2001/04/04 18:21:01 1.2 @@ -61,9 +61,9 @@ if test -z "$gccflag"; then gccflag=-MD, fi - if "$@" -Wp,"$gccflag$tmpdepfile"; then : - else -stat=$? + "$@" -Wp,"$gccflag$tmpdepfile" + stat=$? + if test $stat != 0; then rm -f "$tmpdepfile" exit $stat fi @@ -102,9 +102,9 @@ # trick. Instead we must use -M and then rename the resulting .d # file. This is also the case for older versions of gcc, which # don't implement -Wp. - if "$@" -MD; then : - else -stat=$? + "$@" -MD + stat=$? + if test $stat != 0; then rm -f FIXME exit $stat fi @@ -118,9 +118,7 @@ "$@" -MDupdate "$tmpdepfile" fi stat=$? - if test $stat -eq 0; then : - else -stat=$? + if test $stat != 0; then rm -f "$tmpdepfile" exit $stat fi
testcase for make dist with subdir SOURCES
The attached test csae demonstrates the problem. I don't think I'll have time to step upto the coding plate, but I figure a the test might make things easier ... :] Rob subobj5.test
Re: make dist and sources in subdirs
- Original Message - From: "Akim Demaille" <[EMAIL PROTECTED]> To: "Alexandre Oliva" <[EMAIL PROTECTED]> Cc: "Robert Collins" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Thursday, April 05, 2001 12:56 AM Subject: Re: make dist and sources in subdirs > > "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes: > > Alexandre> On Apr 3, 2001, "Robert Collins" > Alexandre> <[EMAIL PROTECTED]> wrote: > >> Is it expected behaviour for a.o,b.o ans c.o from the above example > >> to be created in ., or in foo/ ? > > Alexandre> Yep > > (Alexandre means `yes, in .'. I figured that :] > >> It would be good if they could be created in foo/ rather than the > >> current directory (in case of name collisions. > > Alexandre> There's an automake option that tells it to keep object > Alexandre> files in subdirs. I don't recall the exact spelling. > > Couldn't find it in the doc (probably still too experimental?), but a > RTFC shows it's subdir-objects. See the subobj*.test files. > Thank you. Rob
Re: make dist and sources in subdirs
- Original Message - From: "Lars J. Aas" <[EMAIL PROTECTED]> To: "Robert Collins" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Thursday, April 05, 2001 5:34 PM Subject: Re: make dist and sources in subdirs > On Thu, Apr 05, 2001 at 09:20:46AM +0200, Lars J. Aas wrote: > : On Thu, Apr 05, 2001 at 08:33:52AM +1000, Robert Collins wrote: > : : I take it the answer to this is "yes it solves creating the directory?" > : : The reason why I was hoping to avoid a Makefile is that it saves a level > : : of recursion during make, and on cygwin that saves time. > : > : I'm doing the same thing for some libraries, and trying to fix the dist > > Scratch that - I'm doing something different. I still need to make the > dist rules more directory-aware, though. > > Lars J > I tried adding a makefile in each leaf dir, and that didn't fix the problem. Adding a DIST_SUBDIRS entry didn't either ..Switching the order of the distdir commands did however: from === distdir: $(DISTFILES) @for file in $(DISTFILES); do \ d=$(srcdir); \ if test -d $$d/$$file; then \ cp -pR $$d/$$file $(distdir) \ || exit 1; \ else \ test -f $(distdir)/$$file \ || cp -p $$d/$$file $(distdir)/$$file \ || exit 1; \ fi; \ done for subdir in $(DIST_SUBDIRS); do \ if test "$$subdir" = .; then :; else \ test -d $(distdir)/$$subdir \ || mkdir $(distdir)/$$subdir \ || exit 1; \ (cd $$subdir && \ $(MAKE) $(AM_MAKEFLAGS) \ top_distdir="$(top_distdir)" \ distdir=../$(distdir)/$$subdir \ distdir) \ || exit 1; \ fi; \ done === to === distdir: $(DISTFILES) for subdir in $(DIST_SUBDIRS); do \ if test "$$subdir" = .; then :; else \ test -d $(distdir)/$$subdir \ || mkdir $(distdir)/$$subdir \ || exit 1; \ (cd $$subdir && \ $(MAKE) $(AM_MAKEFLAGS) \ top_distdir="$(top_distdir)" \ distdir=../$(distdir)/$$subdir \ distdir) \ || exit 1; \ fi; \ done @for file in $(DISTFILES); do \ d=$(srcdir); \ if test -d $$d/$$file; then \ cp -pR $$d/$$file $(distdir) \ || exit 1; \ else \ test -f $(distdir)/$$file \ || cp -p $$d/$$file $(distdir)/$$file \ || exit 1; \ fi; \ done === I haven't dug into the automake sources yet, so perhaps I can just ask - will this cause problems if it was the default? (I know it becomes a depth first search). Perhaps making the directory first and then iterating into after doing the current directories file (if depth first is an issue). This doesn't solve the issue if you are building with sources like foo/bar/abe.c but it will solve foo/bar.c Rob
Re: make dist and sources in subdirs
On Thu, Apr 05, 2001 at 09:20:46AM +0200, Lars J. Aas wrote: : On Thu, Apr 05, 2001 at 08:33:52AM +1000, Robert Collins wrote: : : I take it the answer to this is "yes it solves creating the directory?" : : The reason why I was hoping to avoid a Makefile is that it saves a level : : of recursion during make, and on cygwin that saves time. : : I'm doing the same thing for some libraries, and trying to fix the dist Scratch that - I'm doing something different. I still need to make the dist rules more directory-aware, though. Lars J
Re: make dist and sources in subdirs
On Thu, Apr 05, 2001 at 08:33:52AM +1000, Robert Collins wrote: : I take it the answer to this is "yes it solves creating the directory?" : The reason why I was hoping to avoid a Makefile is that it saves a level : of recursion during make, and on cygwin that saves time. I'm doing the same thing for some libraries, and trying to fix the dist rules with that respect is one of the next things on my agenda. Don't know if I'll get started on this for a while, though, so if anyone else wants to do this I won't object... Lars J
