feature request make dep
Hi! Though I appreciate the automatic dependency tracking mechanism, I sometimes encounter problems with this approach using Intel's C++ compiler. For reasons I do not understand prefixed objects get rebuilt, so either depcomp cannot properly deal with Intel's Compiler (which is handled as if it were a tru64) or there is another yet undetected issue. This means, that dependencies computed as a side effect yield a recompilation. I could not find any problem within the generated Makefile, so I guess it is depcomp to blame. Since the dependencies are fine in general, I would appreciate if I could evoke make dep to handle situations in which the dependency tracking via depcomp fails, just to have some more control on what is going on. Any hints how I can debug the actual situation? Reading through depcomp sources is not too nice a thing to do. Can I use another compiler (e.g. g++) to generate the dependencies? Is there a way to explicitly define the tool neeed to build the dependencies? best regards, Markus
Re: feature request make dep
On Mon, Jul 28, 2003 at 01:09:21PM +0200, Markus Werle wrote: Hi! Though I appreciate the automatic dependency tracking mechanism, I sometimes encounter problems with this approach using Intel's C++ compiler. For reasons I do not understand prefixed objects get rebuilt, so either depcomp cannot properly deal with Intel's Compiler (which is handled as if it were a tru64) or there is another yet undetected issue. Which Automake version are you using? icc 7.0 is supported since Automake 1.7.3 and icc 7.1 since 1.7.6.
Re: feature request make dep
Alexandre Duret-Lutz wrote: On Mon, Jul 28, 2003 at 01:09:21PM +0200, Markus Werle wrote: Hi! Though I appreciate the automatic dependency tracking mechanism, I sometimes encounter problems with this approach using Intel's C++ compiler. For reasons I do not understand prefixed objects get rebuilt, so either depcomp cannot properly deal with Intel's Compiler (which is handled as if it were a tru64) or there is another yet undetected issue. Which Automake version are you using? icc 7.0 is supported since Automake 1.7.3 and icc 7.1 since 1.7.6. I use automake-1.7.5 and icc 7.1 :-( OK, let us give the 1.7.6 version a try Were there some intel-specific issues resolved between 1.7.5 and 1.7.6? cu, Markus
delete aclocal.m4? keep generated files on cvs server? enforcespecefic automake/conf version?
I'm new at developing on POSIX systems, so I have a few questions (as the subject might indicate ;)) Should I include aclocal.m4 in MAINTAINERCLEANFILES, and regenerate it every time i regenerate the built files? (runs autogen.sh) Is it advisable to keep the generated configure and friends on the cvs server, or should I run make maintainer-clean before I commit/import? And last, but not least. ;) How is the proper way to enforce specific automake/autoconf versions in the autogen.sh script? I know some of the questions does apply to autoconf too, but I thought it was most appropriate to ask here, please advice if not. Thanks in advance. -- Bjarke Freund-Hansen [EMAIL PROTECTED]
Re: delete aclocal.m4? keep generated files on cvs server? enforcespecefic automake/conf version?
Bjarke Freund-Hansen wrote: I'm new at developing on POSIX systems, so I have a few questions (as the subject might indicate ;)) Should I include aclocal.m4 in MAINTAINERCLEANFILES, and regenerate it every time i regenerate the built files? (runs autogen.sh) It depends whether you want to expect everyone who might build source from your CVS repository to have all the autotools installed or not. In general, I think most projects choose to check them in. Is it advisable to keep the generated configure and friends on the cvs server, or should I run make maintainer-clean before I commit/import? Same answer, though if you decide against checking them in you could just add the files to the local .cvsignore file to have CVS stop telling you they are around when you don't wich to check them in. And last, but not least. ;) How is the proper way to enforce specific automake/autoconf versions in the autogen.sh script? configure.in: AC_VERSION(autoconf version number) Makefile.am: AUTOMAKE_OPTIONS = automake version number Derek -- *8^) Email: [EMAIL PROTECTED] Get CVS support at http://ximbiot.com! -- Man who run behind car get exhausted.
Re: delete aclocal.m4? keep generated files on cvs server? enforcespecefic automake/conf version?
Hi, Should I include aclocal.m4 in MAINTAINERCLEANFILES, and regenerate it every time i regenerate the built files? (runs autogen.sh) Usually I don't care about that file. It will be regenerated every time someone calls aclocal, so there is no need to clean it out. Is it advisable to keep the generated configure and friends on the cvs server, or should I run make maintainer-clean before I commit/import? That depends on your taste. Personally, I don't put them in CVS, since everyone who uses CVS should know what they are doing and that they are supposed to run autogen.sh, and it clutters up the diffs and generates needless conflicts. Usually I use an autogen.sh like this, works on most systems: #! /bin/sh -ex aclocal-1.7 -I m4 || aclocal-1.6 -I m4 || aclocal -I m4 autoheader automake-1.7 -a || automake-1.6 -a || automake -a autoconf As you probably have found out, setting the x bit before the cvs add will make cvs set the x bit on every checked out version too, which makes it easier for everyone. And last, but not least. ;) How is the proper way to enforce specific automake/autoconf versions in the autogen.sh script? AC_PREREQ() for autoconf and AM_INIT_AUTOMAKE() for automake. The docs tell you more about this. :-) HTH, Simon -- GPG Fingerprint: 040E B5F7 84F1 4FBC CEAD ADC6 18A0 CC8D 5706 A4B4 pgp0.pgp Description: PGP signature
Re: delete aclocal.m4? keep generated files on cvs server? enforcespecefic automake/conf version?
On Mon, Jul 28, 2003 at 11:02:58PM +0200, Simon Richter wrote:
Usually I use an autogen.sh like this, works on most systems:
#! /bin/sh -ex
aclocal-1.7 -I m4 || aclocal-1.6 -I m4 || aclocal -I m4
autoheader
automake-1.7 -a || automake-1.6 -a || automake -a
autoconf
Here's what I use:
#!/usr/bin/env bash
# For the lazy people, this does all the auto* stuff needed before
# ./configure make will work
# (This is a maintainer script; it should never have to be run on
# a distributed tarball)
set -e
${ACLOCAL:-aclocal} -I autoconf
${AUTOHEADER:-autoheader}
${AUTOMAKE:-automake} -a
${AUTOCONF:-autoconf}
# If it exists and is executable, recheck and regenerate
test -x config.status ./config.status --recheck
test -x config.status ./config.status
# Exit true if we got this far
exit 0
The extra calls to config.status are there because it's a damn sight
faster this way than letting automake-generated Makefiles call
config.status once for each subdirectory (which they would otherwise
do on the next build) - this is right, but not what you wanted.
--
.''`. ** Debian GNU/Linux ** | Andrew Suffield
: :' : http://www.debian.org/ |
`. `' |
`- -- |
pgp0.pgp
Description: PGP signature
Re: delete aclocal.m4? keep generated files on cvs server? enforcespecefic automake/conf version?
Andrew == Andrew Suffield [EMAIL PROTECTED] writes:
[...]
Andrew #!/usr/bin/env bash
Andrew # For the lazy people, this does all the auto* stuff needed before
Andrew # ./configure make will work
Andrew # (This is a maintainer script; it should never have to be run on
Andrew # a distributed tarball)
Andrew set -e
Andrew ${ACLOCAL:-aclocal} -I autoconf
Andrew ${AUTOHEADER:-autoheader}
Andrew ${AUTOMAKE:-automake} -a
Andrew ${AUTOCONF:-autoconf}
Andrew # If it exists and is executable, recheck and regenerate
Andrew test -x config.status ./config.status --recheck
Andrew test -x config.status ./config.status
Andrew # Exit true if we got this far
Andrew exit 0
This whole script (including its last part) can be replaced by
autoreconf -im
(I'd use -vfim, though.)
--
Alexandre Duret-Lutz
Re: delete aclocal.m4? keep generated files on cvs server? enforcespecefic automake/conf version?
Derek == Derek Robert Price [EMAIL PROTECTED] writes: Derek Bjarke Freund-Hansen wrote: I'm new at developing on POSIX systems, so I have a few questions (as the subject might indicate ;)) Should I include aclocal.m4 in MAINTAINERCLEANFILES, and regenerate it every time i regenerate the built files? (runs autogen.sh) Derek It depends whether you want to expect everyone who might build source Derek from your CVS repository to have all the autotools installed or not. See also the Automake manual. http://sources.redhat.com/automake/automake.html#FAQ -- Alexandre Duret-Lutz
Re: delete aclocal.m4? keep generated files on cvs server? enforcespecefic automake/conf version?
On Mon, Jul 28, 2003 at 11:39:48PM +0200, Alexandre Duret-Lutz wrote: Andrew == Andrew Suffield [EMAIL PROTECTED] writes: [...] snip This whole script (including its last part) can be replaced by autoreconf -im (I'd use -vfim, though.) autoreconf has a habit of doing silly things like running autopoint, which then cheerfully adds a bunch of gunk to the source tree which you didn't want. I've never seen it actually do what I wanted, and frankly, it's far too complicated for what should be a trivial script. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | pgp0.pgp Description: PGP signature
Re: delete aclocal.m4? keep generated files on cvs server? enforcespecefic automake/conf version?
Hi, Andrew Suffield [EMAIL PROTECTED] writes: On Mon, Jul 28, 2003 at 11:39:48PM +0200, Alexandre Duret-Lutz wrote: Andrew == Andrew Suffield [EMAIL PROTECTED] writes: [...] snip This whole script (including its last part) can be replaced by autoreconf -im (I'd use -vfim, though.) autoreconf has a habit of doing silly things like running autopoint, which then cheerfully adds a bunch of gunk to the source tree which you didn't want. I've never seen it actually do what I wanted, and frankly, it's far too complicated for what should be a trivial script. It does that only when you ask for 'gettext'. On most modern machines, esp. on Debian, you should replace AM_GNU_GETTEXT with AM_GNU_GETTEXT_VERSION([0.12.1]) # or appropriate version AM_GNU_GETTEXT([external]) and thinks will be peachier. - Hari -- Raja R Harinath -- [EMAIL PROTECTED]
Re: delete aclocal.m4? keep generated files on cvs server? enforcespecefic automake/conf version?
On Mon, Jul 28, 2003 at 05:33:43PM -0500, Raja R Harinath wrote: Hi, Andrew Suffield [EMAIL PROTECTED] writes: autoreconf has a habit of doing silly things like running autopoint, which then cheerfully adds a bunch of gunk to the source tree which you didn't want. I've never seen it actually do what I wanted, and frankly, it's far too complicated for what should be a trivial script. It does that only when you ask for 'gettext'. On most modern machines, esp. on Debian, you should replace AM_GNU_GETTEXT with AM_GNU_GETTEXT_VERSION([0.12.1]) # or appropriate version AM_GNU_GETTEXT([external]) and thinks will be peachier. All that does is stop including a complete copy of libintl in your source tree. autopoint still wants to add a few dozen files. The best solution is to not run autopoint at all, since it doesn't do anything useful if you don't want to include a copy of gettext in your distributed tarballs. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -- | pgp0.pgp Description: PGP signature
Re: delete aclocal.m4? keep generated files on cvs server? enforcespecefic automake/conf version?
Andrew Suffield [EMAIL PROTECTED] writes: On Mon, Jul 28, 2003 at 05:33:43PM -0500, Raja R Harinath wrote: Andrew Suffield [EMAIL PROTECTED] writes: autoreconf has a habit of doing silly things like running autopoint, which then cheerfully adds a bunch of gunk to the source tree which you didn't want. I've never seen it actually do what I wanted, and frankly, it's far too complicated for what should be a trivial script. It does that only when you ask for 'gettext'. On most modern machines, esp. on Debian, you should replace AM_GNU_GETTEXT with AM_GNU_GETTEXT_VERSION([0.12.1]) # or appropriate version AM_GNU_GETTEXT([external]) and thinks will be peachier. All that does is stop including a complete copy of libintl in your source tree. autopoint still wants to add a few dozen files. The best solution is to not run autopoint at all, since it doesn't do anything useful if you don't want to include a copy of gettext in your distributed tarballs. But, you asked for with AM_GNU_GETTEXT. AFAIR, the files are all limited to the po/ directory, and they're all used either by AM_GNU_GETTEXT or po/Makefile.in.in. The only issue with upgrading from previous versions of po/Makefile.in.in is that you have to create po/Makevars, which you can do once and for all with sed 's,^MSGID_BUGS_ADDRESS =, [EMAIL PROTECTED],' po/Makevars.template po/Makevars You can check in po/Makevars into the CVS repository. - Hari -- Raja R Harinath -- [EMAIL PROTECTED]
