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
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
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
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: 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 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: 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: 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: 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: 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)
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: 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: -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: 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: 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: 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
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
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
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: 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
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: 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: 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
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
