Re: Alternative compiling for debug/optimized code?
On Thu, Dec 08, 2005 at 01:37:26PM +0100, Ralf Wildenhues wrote:
> > but most of th time I don't need debug code, so I want to disable that
> > -g - option.
>
> So standard way with Automake-using projects would be: you make a debug
> build tree and a normal (optimized) build tree:
>
> mkdir build-debug build
> cd build-debug
> ../source-tree/configure CFLAGS=-g
> make
>
> cd ../build
> ../source-tree/configure CFLAGS=-O3
> make
This is really an autoconf thing, but I go one step further and use
the construction at the end of this mail. I have similar (although
less complex) constructs for stuff like -g, -pg, etc. It detects the
default flags to use based on the presence of a file 'development' in
the source tree. This file is present in the revision-controlled tree
where development work happens (and therefore you do a lot of
debugging), but which automake does not put into the 'make dist'
tarballs, so end-users get the optimised version instead.
That said, I almost always put -g in there by default regardless,
because with the exception of huge projects or complex C++ features,
it doesn't cost anything noticable and occasionally it's useful. I'm
assuming here that for production use, the binaries will get packaged
and stripped at that point - which means you've installed the files
stripped, but your build tree has the debugging symbols if you need
them later (and which can be used to decode any core dumps produced by
the stripped binaries).
AC_MSG_CHECKING(for suitable optimisation flags)
AC_ARG_ENABLE(optimise,
[ --enable-optimise Enable optimisation ],
[if test "$enableval" = "yes"
then
if test "$GCC" = "yes"
then
optimise='-Os '
else
optimise='-O '
fi
else
if test "$GCC" = "yes"
then
optimise='-O0 '
else
optimise=''
fi
fi],[
if test -f "$srcdir/development"
then
if test "$GCC" = "yes"
then
optimise='-O0 '
else
optimise=''
fi
else
if test "$GCC" = "yes"
then
optimise='-O2 '
else
optimise='-O '
fi
fi
])
if test -z "${optimise}"
then
AC_MSG_RESULT(none)
else
AC_MSG_RESULT(${optimise})
fi
Yes, I'm aware this has duplicated code and should be refactored.
--
.''`. ** Debian GNU/Linux ** | Andrew Suffield
: :' : http://www.debian.org/ |
`. `' |
`- -><- |
signature.asc
Description: Digital signature
Re: Source files generation
On Sat, Jul 30, 2005 at 03:26:43PM +0200, Thomas Degris wrote: > lib_LTLIBRARIES = libtoto.la > > dist_libtoto_la_SOURCES = src/toto.stc > libtoto_la_SOURCES =src/toto01.cxx src/toto02.cxx src/toto.cpp > > %.cxx: src/diary.xml > > src/diary.xml: src/toto.stc >gencxx src/toto.stc > > The problem with this approach is that make returns the error : > *** No rule to make target 'src/toto01.cxx', needed by > 'libtoto_la-toto01.lo'. Stop. > So, I guess the pattern %.cxx is not correct but I tried different > things and I can't make it work. Any ideas ? You need some actual dependencies. Add something like this: $(cxx_files): src/diary.xml Pattern rules that don't have any actions are generally of limited use, partly because make tends to ignore them. Also, this makefile can get stuck. If src/diary.xml is up to date WRT src/toto.stc but the cxx files are not, for whatever reason (like somebody mangling the tree by hand), then make has nothing to do but the cxx files won't get built. So it breaks. One way to write this better is like this: src/diary.xml $(cxx_files): cxx_stamp cxx_stamp: src/toto.stc gencxx src/toto.stc touch cxx_stamp CLEANFILES += cxx_stamp I think that'll do what you want. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
Re: Configuring automake says autoconf 2.58 or higher needed. Have au toconf 2.59 installed. What is/goes wrong?
On Mon, Jan 17, 2005 at 08:39:16AM +1100, Robert Collins wrote: > On Sun, 2005-01-16 at 07:01 -0500, Thomas Dickey wrote: > > On Sun, 16 Jan 2005, Ralf Corsepius wrote: > > > > > On Sat, 2005-01-15 at 13:15 +0100, Alexandre Duret-Lutz wrote: > > > > > >> PS: I know this is not the first time, but I simply do not > > >> understand why you respond to bug reports without Cc: the > > >> reporter. > > > I normally respond CC:-ing the reporter on auto*.gnu.org lists, because > > > they tend to be unreliable. Not have done so in this case was just an > > > oversight. > > > > otoh, when I do that, I usually get 2-3 complaints from people stating > > that I shouldn't (ymmv). > > They should configure their mail system appropriately so that they don't > see duplicates. (for example, see 'man formail'). That's entirely useless, and often worse than receiving duplicates; it is fundamentally incompatible with any non-trivial filtering of mail into multiple folders. It destroys duplicates due to crossposts (which is wrong; crossposts *should* be received multiple times, one per folder, so that threading is maintained), and it keeps the first copy received rather than the correct one. Since mailing lists are usually slower than direct mail, it usually destroys all but the personal copy, which is the one you *didn't* want. The only possible solution on the receiving end is to simply discard all personal mail from people who repeatedly send you useless copies (I maintain a specialised killfile for this); in effect, abuse of the privilege of sending personal mail leads to its revocation. Only the sender can do anything better than this, because they're the only one with the necessary information. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
Re: Disabling optimization
On Fri, Nov 19, 2004 at 05:58:58PM +0100, [EMAIL PROTECTED] wrote: > >>>>> "Andrew" == Andrew Suffield <[EMAIL PROTECTED]> writes: > > Andrew> Uh, that made no sense at all. Are you saying that you should not > Andrew> write code, because it's not possible to write code that works on > Andrew> every platform? > >> > >> What he is trying to say (I believe) is that it is not a good habit to > >> write nonportable code because you are too lazy to even think about > >> portability, and to try to persuade other to do so as well. The former > >> is your own problem, while the latter is not. > > Andrew> It's certainly not a good habit to write lousy code because you're too > Andrew> lazy to consider which platforms your application is going to run on, > Andrew> or to persuade other people to write lousy code because your platform > Andrew> is crippled. > > I'm not a particular fan of HP-UX, but I still don't see why the lack > of the native compiler's -O0 option would render a platform crippled. It makes fine-grained control of compiler options somewhere between difficult and impossible. Without properly negatable options, the best you can do is cheap all-or-nothing hacks (see earlier in this thread for several examples), where the user can only deactivate all the logic in the configure script and do it by hand. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
Re: Disabling optimization
On Fri, Nov 19, 2004 at 09:43:30AM -0600, Bob Friesenhahn wrote: > On Fri, 19 Nov 2004, Andrew Suffield wrote: > >> aCC: warning 901: unknown option: `-0': use +help for online > >> documentation. > > > >I don't remember the last time I wrote anything that worked on HP-UX; > >it's certainly not a platform I have any interest in supporting. I > >mean, geez, next you'll be complaining that it doesn't work on VMS. > > > >If you're going to deal with freakish systems like this, then yes, > >you're going to have to go to the lowest-common-denominator. But > >that's no reason why those of us not stuck in the 1980s should care. > > > >For any feature you care to consider, ABSOLUTELY ANY FEATURE YOU HAVE > >EVER USED, there exists a platform on which it does not work. That > >does not mean you should not write any code. > > While I agree that from certain programming standpoints HP-UX leaves > much to be desired it also happens to be one of the current dominant > OSs of choice for big-iron Unix systems, and is therefore not an > obscure "freakish" system. All the HP-UX sysadmins I've encountered disagree with you on both points (although 'dominant OSs of choice for ' can mean just about anything). They generally only use it because either (a) they can't afford a hardware upgrade, or (b) they have some weird proprietary application that won't run on anything else. > My software works fine under HP-UX. You software should work under > HP-UX as well. What for? Nobody wants to use it there. It's a far better use of time to do things people actually want. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
Re: Disabling optimization
On Fri, Nov 19, 2004 at 05:07:48PM +0100, [EMAIL PROTECTED] wrote: > >>>>> "Andrew" == Andrew Suffield <[EMAIL PROTECTED]> writes: > > Andrew> On Fri, Nov 19, 2004 at 07:00:43AM -0500, Thomas Dickey wrote: > >> On Fri, 19 Nov 2004, Andrew Suffield wrote: > >> > >> >For any feature you care to consider, ABSOLUTELY ANY FEATURE YOU HAVE > >> >EVER USED, there exists a platform on which it does not work. That > >> >does not mean you should not write any code. > >> > >> Perhaps you don't choose to do good work, but don't try to persuade others > >> to do less. > > Andrew> Uh, that made no sense at all. Are you saying that you should not > Andrew> write code, because it's not possible to write code that works on > Andrew> every platform? > > What he is trying to say (I believe) is that it is not a good habit to > write nonportable code because you are too lazy to even think about > portability, and to try to persuade other to do so as well. The former > is your own problem, while the latter is not. It's certainly not a good habit to write lousy code because you're too lazy to consider which platforms your application is going to run on, or to persuade other people to write lousy code because your platform is crippled. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
Re: Disabling optimization
On Fri, Nov 19, 2004 at 08:49:29AM -0500, Thomas Dickey wrote: > On Fri, 19 Nov 2004, Andrew Suffield wrote: > > >Uh, that made no sense at all. Are you saying that you should not > >write code, because it's not possible to write code that works on > >every platform? > > That was the message one would infer from the remainder of your comment. Did you not read it? Everything I said was arguing *against* this. I think you have me confused with the parent message. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
Re: Disabling optimization
On Fri, Nov 19, 2004 at 07:00:43AM -0500, Thomas Dickey wrote: > On Fri, 19 Nov 2004, Andrew Suffield wrote: > > >For any feature you care to consider, ABSOLUTELY ANY FEATURE YOU HAVE > >EVER USED, there exists a platform on which it does not work. That > >does not mean you should not write any code. > > Perhaps you don't choose to do good work, but don't try to persuade others > to do less. Uh, that made no sense at all. Are you saying that you should not write code, because it's not possible to write code that works on every platform? -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
Re: Disabling optimization
On Fri, Nov 19, 2004 at 12:42:43AM -0700, Bob Proulx wrote:
> Bob Friesenhahn wrote:
> > Andrew Suffield wrote:
> > >>>What you're all trying to say is this:
> > >>>
> > >>>CXXFLAGS="-g -O0 ${CXXFLAGS}"
> > >>Nope, this prevents overriding CXXFLAGS from the environment.
> > >
> > >It does not. I do it all the time.
>
> On HP-UX:
>
> aCC -O0
> aCC: warning 901: unknown option: `-0': use +help for online documentation.
I don't remember the last time I wrote anything that worked on HP-UX;
it's certainly not a platform I have any interest in supporting. I
mean, geez, next you'll be complaining that it doesn't work on VMS.
If you're going to deal with freakish systems like this, then yes,
you're going to have to go to the lowest-common-denominator. But
that's no reason why those of us not stuck in the 1980s should care.
For any feature you care to consider, ABSOLUTELY ANY FEATURE YOU HAVE
EVER USED, there exists a platform on which it does not work. That
does not mean you should not write any code.
--
.''`. ** Debian GNU/Linux ** | Andrew Suffield
: :' : http://www.debian.org/ |
`. `' |
`- -><- |
signature.asc
Description: Digital signature
Re: Disabling optimization
On Thu, Nov 18, 2004 at 03:44:46PM -0600, Bob Friesenhahn wrote:
> On Thu, 18 Nov 2004, Andrew Suffield wrote:
> >>>What you're all trying to say is this:
> >>>
> >>>CXXFLAGS="-g -O0 ${CXXFLAGS}"
> >>Nope, this prevents overriding CXXFLAGS from the environment.
> >
> >It does not. I do it all the time.
>
> How does the user portably remove/override the -g and -O0 options? It
> seems that you are depending on the user's compiler to support a way
> to subtract from existing options. You are also expecting that the
> user's compiler supports -O0 and doesn't simply exit.
You appear to be expecting the user's compiler to compile C++. That's
a pretty poor expectation from the outset (it might be g++ 2.95 or
something).
You can't do *anything* without expecting stuff from the
compiler. Pick some real goals and some realistic expectations, don't
just handwave about vague notions of 'portability' to unnamed systems
which are broken in unspecified ways.
--
.''`. ** Debian GNU/Linux ** | Andrew Suffield
: :' : http://www.debian.org/ |
`. `' |
`- -><- |
signature.asc
Description: Digital signature
Re: Disabling optimization
On Thu, Nov 18, 2004 at 01:42:39PM +0100, Ralf Corsepius wrote:
> On Thu, 2004-11-18 at 11:56 +0000, Andrew Suffield wrote:
> > On Thu, Nov 18, 2004 at 12:41:37PM +0100, Ralf Corsepius wrote:
> > > On Thu, 2004-11-18 at 11:55 +0100, Andreas Schwab wrote:
> > > > Stepan Kasal <[EMAIL PROTECTED]> writes:
> > > >
> > > > > out of curiosity, what would be wrong with the following?
> > > > >
> > > > > if test -n "${CXXFLAGS}"; then
> > > > > CXXFLAGS="-g"
> > > > > fi
> > > > > AC_PROG_CXX
> > > >
> > > > I think you got it backwards. This makes it impossible to override
> > > > CXXFLAGS.
> > >
> > > Isn't the snippet below sufficient?
> > > CXXFLAGS=${CXXFLAGS--g}
> > > AC_PROG_CXX
> >
> > What you're all trying to say is this:
> >
> > CXXFLAGS="-g -O0 ${CXXFLAGS}"
> Nope, this prevents overriding CXXFLAGS from the environment.
It does not. I do it all the time.
--
.''`. ** Debian GNU/Linux ** | Andrew Suffield
: :' : http://www.debian.org/ |
`. `' |
`- -><- |
signature.asc
Description: Digital signature
Re: Disabling optimization
On Thu, Nov 18, 2004 at 12:41:37PM +0100, Ralf Corsepius wrote:
> On Thu, 2004-11-18 at 11:55 +0100, Andreas Schwab wrote:
> > Stepan Kasal <[EMAIL PROTECTED]> writes:
> >
> > > out of curiosity, what would be wrong with the following?
> > >
> > > if test -n "${CXXFLAGS}"; then
> > > CXXFLAGS="-g"
> > > fi
> > > AC_PROG_CXX
> >
> > I think you got it backwards. This makes it impossible to override
> > CXXFLAGS.
>
> Isn't the snippet below sufficient?
> CXXFLAGS=${CXXFLAGS--g}
> AC_PROG_CXX
What you're all trying to say is this:
CXXFLAGS="-g -O0 ${CXXFLAGS}"
--
.''`. ** Debian GNU/Linux ** | Andrew Suffield
: :' : http://www.debian.org/ |
`. `' |
`- -><- |
signature.asc
Description: Digital signature
Re: Extending automake
On Sun, Aug 01, 2004 at 03:47:36PM -0400, Chris Lee wrote: > Even removing the ability to provide the foo_METASOURCES = AUTO would be > fine with me if I could at least do 'foo_METASOURCES = foo.moc bar.moc' > but at the moment I still don't quite grok how to do that. I generally do this sort of thing (three times now) by writing a perl script that generates makefile chunks, which I have include directives for. This script handles any appropriate scanning or higher-level input files and rule generation. With a little imagination and *proper* development work (not the ham-handed effort that many people, especially projects like KDE, tend to put into their build systems) it can be done neatly, maintainably, and with a minimum of fuss. I don't believe it's possible without adding an extra pass. Nor does it seem particularly useful to do so. The trick is to not do it stupidly, like the current KDE build system does. There's no reason why the higher-level description should pretend to be a Makefile.am. Don't "customize" the automake input format - make up your own in a way that's appropriate to the problem (possibly you can do it with no input file at all, and just hardcode the behaviour into the generating script), and generate classic makefile chunks, then feed these back to automake with include directives. As a matter of form I try to generate makefile chunks that just contain variable definitions (and sometimes dependencies), and put the rules and automake variables into the Makefile.am proper - even if I end up with "foo_SOURCES = $(foo_sources)". If I have rules that are common to several makefiles, I use something like "include $(top_srcdir)/build-misc/docbook.mk". -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
Re: distcheck bug
On Thu, Jul 15, 2004 at 05:28:30PM -0500, Bob Friesenhahn wrote: > On Thu, 15 Jul 2004, Bob Friesenhahn wrote: > > > >It seems that LDFLAGS is being passed but not CC and CXX even though those > >were also specified on the configure command line. Why aren't all the > >standard Autoconf variables saved and replayed? > > I was wrong. It seems that the user specified LDFLAGS is not passed > to configure either. > > So now I am testing with > > DISTCHECK_CONFIGURE_FLAGS='CC=$(CC)' 'CXX=$(CXX)' 'CPPFLAGS=$(CPPFLAGS)' > 'LDFLAGS=$(LDFLAGS)' > > Unfortunately, these values may be extended or altered by the > time they are saved in the Makefile. It will extra configure work to > preserve the user-provided values. I habitually do something like this anyway (duplicated for every variable I mangle in configure): orig_CFLAGS="$CFLAGS" [detect some stuff...] CFLAGS="$foo_CFLAGS $bar_CFLAGS $orig_CFLAGS" [detect some more stuff...] CFLAGS="$foo_CFLAGS $bar_CFLAGS $baz_CFLAGS $orig_CFLAGS" Since that's the only sane way I can come up with to make 'CFLAGS=foo ./configure' work, and still keep a complicated configure.ac readable. So I'd just AC_SUBST(orig_CFLAGS) and stuff that into DISTCHECK_CONFIGURE_FLAGS, under the assumption that the configure script is supposed to sort it out given that input. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
Re: backslashes in variable definition
On Mon, Jun 21, 2004 at 04:38:23PM +0200, Volker Boerchers wrote:
> the _SOURCES values of our Makefile.am's are split into multiple lines
> to improve readability like this
>
> libfoo_la_SOURCES = \
> foo.c \
> bar.c
>
> However if one forgets a backslash the source files after that are
> silently ignored by automake.
>
> libfoo_la_SOURCES = \
> foo.c # missing '\'
> bar.c
>
> These errors are hard to detect, at least for libraries since missing
> dependencies are detected later.
You should see the error you get if you do this:
libfoo_la_SOURCES = \
# foo.c \
bar.c
--
.''`. ** Debian GNU/Linux ** | Andrew Suffield
: :' : http://www.debian.org/ |
`. `' |
`- -><- |
signature.asc
Description: Digital signature
Re: location of .h's in library
On Fri, Jun 18, 2004 at 03:13:55PM -0400, Daniel Reed wrote: > (So, don't split by source file, but do split by component or task.) Split your source files that way too. Then you get the "one header per source file" effect most of the time - but it's completely coincidental (sometimes you get several source files to one header; if you've got several headers implemented in one source file, you're probably doing it wrong). -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
Re: excessive bounces
On Thu, May 27, 2004 at 10:12:19AM +0100, Lars Hecking wrote: > > I believe that all of the SourceForge lists are also open. They used > > to support blocking non-subscribers but that became a nightmare for > > maintainers so the capability was removed. > > SourceForge uses SpamAssassin. Just for comparison, out of the 1600 spam > emails I have archived since last September, 211 came from SF. 635 from > the autoconf and automake lists. These are spam emails that made it through > the primary defences on the mail gateway. I am subscribed to 2 gnu.org lists, > and probably about 10 SF lists, on and off. > > I have received email on the issue by Paul Fisher of the FSF, but I don't > want to repost it here w/o his permission (and because it's off-topic). In > my reply, I have outlined a few things that could be done: > > o gnu.org has a prohibitively high volume of email, and SA/Bayes require >massive resources. Therefore, the volume of mail going through SA or >any other tool must be limited. > > o Excessive whitelisting: all current gnu.org subscribers should be white- >listed, so that their email bypasses anti-spam. Yes, that'll still leave >the problem of subscribed spammers, but I believe there won't be too many. > > o SMTP from hosts not in the gnu.org domain, but HELO'ing as gnu.org or >the associated IP addresses must be refused flat out. That cuts out >many viruses/worms, and a good bit of spam, too. > > o Ruthless use of DNS blacklists before mails reach anti-spam. Most of >spam on GNU lists originates from "known bad boys" - Korea, China, >dialup/dyn-ip hosts, Comcast, *bell etc. Recommended reading: >http://makeashorterlink.com/?D20312968. >sbl-xbl.spamhaus.org alone would probably work wonders. As another data point, look at these numbers for lists.debian.org: http://www.redellipse.net/stuff/Debian/spam-counts.story Summary: 96.5% of all inbound mail is blocked as spam. This is done without using any pansy address obfuscation, scattershot DNS blacklists, or (m)any closed lists. And one fairly slow server, which is not delivering any mail that has not been checked with spamassassin, although the bayes tests are not used, but these aren't too useful anyway; they require continual human intervention on a scale comparable to the volume of mail, which is too damn big. I expect this is a similar order of magnitude mail volume as mail.gnu.org deals with. (Talk to the listmasters if you're interested in *how* this is accomplished, I don't know the details). -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
Re: confused: $DISTDIR not recognized by distcheck
On Mon, May 17, 2004 at 11:17:51AM +0200, Richard Bos wrote: > Makefile.am > install-data-hook: > echo DEBUG DEBUG DEBUG DEBUG DEBUG DEBUG DEBUG DEBUG > echo DESTDIR $(DESTDIR) > for i in cgi-bin icons; do \ > install -d -m 0755 $(DESTDIR)/srv/server/www/cgi-bin/$$i; \ > done > for i in freebusy locks; do \ > install -d -m 0777 $(DESTDIR)/srv/server/www/cgi-bin/$$i; \ > done > echo DEBUG DEBUG DEBUG DEBUG DEBUG DEBUG DEBUG DEBUG You need $(prefix) in every path. You need $(DESTDIR) in any rules you write by hand; rules generated by automake will already contain it. This would work: install -d -m 0755 $(DESTDIR)$(prefix)/srv/server/www/cgi-bin/$$i; \ This would be saner: cgibindir = $(prefix)/srv/server/www/cgi-bin ... install -d -m 0755 $(DESTDIR)$(cgibindir)/$$i; \ And this is better still: cgibindir = $(prefix)/srv/server/www/cgi-bin cgibin_DATA = icons freebusy locks (Leaving the problem of generating rules to automake) What you really want is this: srvdir = @srvdir@ cgibindir = $(srvdir)/server/www/cgi-bin cgibin_DATA = icons freebusy locks But it's difficult to persuade configure to set @srvdir@ appropriately. With "make DESTDIR=/foo install", DESTDIR=/foo and prefix=/bar; with distcheck, prefix=$(CURDIR)/foo/ and DESTDIR=, think it through. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
Re: how to address a directory as /srv
On Sat, May 15, 2004 at 08:49:07AM +0200, Richard Bos wrote: > Op zaterdag 15 mei 2004 03:31, schreef Andrew Suffield: > > > Makefile.am > > > wsadmindir = $(DESTDIR)/srv/www/html/server/admin > > > > ^^ > > > > That's wrong. Take it out. Automake already supports DESTDIR natively; > > you're just stuffing it in the path twice. > > It improve's the 'make DESTDIR= install' command. This one is now > succesfull. The 'make distcheck' still fails with the 'no permission': > /bin/sh ../mkinstalldirs /srv/www/html/server/admin/addressbook > mkdir -p -- /srv/www/html/server/admin/addressbook > mkdir: cannot create directory `/srv/www/html': Permission denied > make[3]: *** [install-wsaddressbookDATA] Error 1 Ah, you need a $(prefix) in there, and you really want to add a --srvdir argument to configure - but I don't think autoconf exposes an interface for doing that. You probably want to start by getting /srv explicitly supported by autoconf. Usual batch of --prefix problems apply. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
Re: how to address a directory as /srv
On Fri, May 14, 2004 at 11:03:47PM +0200, Richard Bos wrote: > I have the following challenge; install something in a directory /srv (for > apache). I use the following code for that: > > Makefile.am > wsadmindir = $(DESTDIR)/srv/www/html/server/admin ^^ That's wrong. Take it out. Automake already supports DESTDIR natively; you're just stuffing it in the path twice. I think that's your only problem here. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
Re: FEATURE REQUEST: make uninstall should delete empty directories.
On Tue, Mar 02, 2004 at 05:00:14PM -0500, Eric Siegerman wrote: > On Tue, Mar 02, 2004 at 08:34:19AM -0600, Bob Friesenhahn wrote: > > If a package supports creating the directory /usr/local (as Automake > > does by default) should this directory be recursively removed if a > > package is uninstalled? > > Absolutely not! (I rather suspect the question was rhetorical, > but I'm answering it anyway :-) Nor will it, because /usr/local will never be empty. > Thus, if I'm right that Automake doesn't know which directories > the package owns, it should should err on the side of caution: it > should *not* try to delete any empty directories at uninstall > time. Neither should Automake try to guess -- guesses involving > the "rm" command, especially as root, are a really dangerous > idea! That's why you use the rmdir command. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
Re: release schedule for 1.9? (Was: Re: automake -vs- huge projects (1st patch))
On Thu, Jan 22, 2004 at 04:54:33PM -0700, Tom Tromey wrote: > >>>>> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes: > > adl> Also, since we have switched to API-numbering, bumping that > adl> version number has a cost. For instance Debian distributes > adl> automake1.4, automake1.6, automake1.7, and automake1.8. If we > adl> add another API, it'd better be worth it. > > Yeah. It turns out that Red Hat still ships 1.5 because some packages > still depend on it. Sigh. Obviously this doesn't scale -- at some > point it has to be so painless to upgrade that someone like Debian or > Red Hat can simply ditch 1.x and convert everything to 1.x+1 all at > once. Frankly, the reason Debian is carrying so many versions is because maintainers are bloody lazy. Every transition of this form takes ages, no matter how easy it is to convert. Half the time there's nothing that needs to be done aside from actually using a newer version, and it still doesn't get done. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
AC_CONFIG_FILES and Makefile.am
On one project, I have over 60 entries in AC_CONFIG_FILES that are derived from Makefile.ams. This is getting to be irritating to maintain. Is there any good reason why there isn't an AM_CONFIG_MAKEFILES macro that computes a list of makefiles by following SUBDIRS variables in the Makefile.ams, and calls AC_CONFIG_FILES appropriately? (I'll implement it myself if I have to) -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
Re: config.guess and freedom (was: 1.8 and mkdir_p)
On Thu, Jan 08, 2004 at 10:53:58AM +, Gary V. Vaughan wrote: > Ralf Corsepius wrote: > | Sorry for having to say this, but IMO, configure scripts relying on > | config.guess'ed values are "badly designed and fundamentally flawed". > > It's a pity you think that. I always found libtool to be rather useful. Useful yes, but fundamentally flawed in implementation (in this and a few other respects). This particular one has been the cause of many libtool bugs and accidental misfeatures before now. Libtool is firmly in the "Nice idea, pity it doesn't suck less, use it anyway because it's all we've got" box. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
Re: Expressing dependencies
On Sun, Jan 04, 2004 at 09:39:28AM +1100, Robert Collins wrote: > On Sun, 2004-01-04 at 08:17, Laurence Finston wrote: > > > The problem is that make makes certain assumptions that don't apply when CWEB > > is used. > > I think thats an incorrect statement. It would be more accurate to say > that CWEB hasn't been built with any thought to the impact on make. Make > has only the file system data available to it to determine 'has X > changed more recently than Y.' config.status for example, when it > regenerates config.h will only alter the file if the contents have > changed - so that it preserves the timestamp. I think that most > pre-preocessors in this sense could benefit from a wrapper of some sort > that would equally not alter the file IF nothing had changed - and you > could use that wrapper directly in make rules for ctangle. It may be worth noting that bison and flex, as invoked by automake, have comparable issues with their ancillary files (especially bison-generated headers). I never managed to figure a way to have those work sanely with make either, let alone automake. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
Re: 1.8 and mkdir_p
On Sat, Jan 03, 2004 at 04:25:47PM +0100, Alexandre Duret-Lutz wrote: > - is it normal to honor umask when creating directories and not >when installing files? I'd say it was normal to honour umask at all times. People who ask for applications to ignore umask because they have a silly umask set, usually need repeatedly kicking in the head. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
Re: convenience binaries
On Mon, Sep 22, 2003 at 10:01:24PM +1000, Robert Collins wrote: > On Mon, 2003-09-22 at 21:22, Warren Turkal wrote: > > Robert Collins wrote: > > > yes, > > > noinst_PROGRAMS = convenience_binaries > > > > Can these convenience programs be built for the host arch in a > > cross-compiled environment? > > probably, you'll likely need to override the default build recipe > though.. I haven't tried, perhaps someone else here has more details. Can it ever be correct for a noinst object to be built for the target environment? By definition, they should only exist on the build system. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
Re: automake and (f)lex
On Thu, Aug 07, 2003 at 01:53:05PM +0100, Simon Waters wrote: > Couldn't figure out why automake was including the ".c" file for the lex > code when doing "make dist". > > Eventually read the manual ;-) Which said this is what it is suppose to do. > > Since the generated C code isn't portable it breaks the normal > "./configure; make" build procedure on one of the target platforms. > > Evil hacks are easy to avoid this, but why does it do this, and is there > a "right way" of stopping it, or should I do something clever to make > the generated C portable? Recent versions of flex are a dead loss; I'd stick with 2.5.4 until the flex maintainers start responding to mail, or at least fixing bugs. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | pgp0.pgp Description: PGP signature
Re: (no subject)
On Thu, Jul 31, 2003 at 11:53:52PM +0200, Alexandre Duret-Lutz wrote:
> It will still remain a few files at the top-level, like
> ./configure{,.ac}, aclocal.m4 and Makefile.{in,am}, but I'm
^^
> afraid you'll have to live with them. Uniformity matters most
> than personal taste.
Doesn't appear to apply to aclocal.m4, it should be safe to transition
that into AC_CONFIG_AUX_DIR or someplace.
--
.''`. ** 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?
On Wed, Jul 30, 2003 at 03:27:37PM -0500, Raja R Harinath wrote:
> >> > 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.
> >
> > No, there are about half a dozen files in po/ which aren't needed, and
> > then there's all the m4 macros.
>
> Sorry to keep harping on this. I'm trying to figure out if we should
> report this as a bug to the gettext maintainer or not.
>
> Having m4 macros in the source tree is better IMHO. You have better
> control over the sources that you're building. Also, there's a
> matched set of m4/{gettext,po,...}.m4 and po/Makefile.in.in -- which
> is good. Also, with 'aclocal' 1.8, this is pretty cheap, since the
> they'll just put
>
> m4_include([m4/gettext.m4])
> m4_include([m4/po.m4])
> etc.
>
> into aclocal.m4. There's no need for m4/Makefile.am, since they're
> automatically distributed, and all that jazz. The whole thing is now
> very lightweight.
I don't want them distributed at all. You can't regenerate much of the
build system without having autoconf, automake and gettext installed
anyway - and if gettext is installed, the files are present in
/usr/share/aclocal*/ somewhere. Dragging the files around in the
source tree is unnecessary duplication.
This is approximately equivalent to automake putting a copy of all the
.am files into the source tree.
> As to the files in po/. Apart from po/Makefile.in.in, I see the
> following:
>
> Rules-quot
> boldquot.sed
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
> insert-header.sin
> quot.sed
> remove-potcdate.sin
>
> All the script fragments are used by Rules-quot. That file isn't
> directly referred to by Makefile.in.in. However, Rules-quot is
> appended to the generated po/Makefile by m4/po.m4.
>
> for f in "$ac_given_srcdir/$ac_dir"/Rules-*; do
> if test -f "$f"; then
> case "$f" in
> *.orig | *.bak | *~) ;;
> *) cat "$f" >> "$ac_dir/Makefile" ;;
> esac
> fi
> done
>
> As to the utility of this whole set of files: I can't judge. If I'm
> not mistaken, they seem to be for the use of the translation team to
> automatically generate simple variants of the messages that are more
> suitable to an 'en_US' locale than those of the 'C' locale -- assuming
> you use ISO8859-1 rather than 7-bit ASCII.
Most of them are associated with the automatically-generated [EMAIL PROTECTED]
and [EMAIL PROTECTED] locales. If you don't explicitly generate these,
then the files are never referenced and can be deleted.
--
.''`. ** Debian GNU/Linux ** | Andrew Suffield
: :' : http://www.debian.org/ |
`. `' |
`- -><- |
pgp0.pgp
Description: PGP signature
Re: automake and shared libraries
On Tue, Jul 29, 2003 at 02:34:14PM +0200, Mattias Br?ndstr?m wrote: > On Tue, 29 Jul 2003, Alexandre Duret-Lutz wrote: > > > On Tue, Jul 29, 2003 at 01:16:53PM +0200, Mattias Br?ndstr?m wrote: > > [...] > > > automake: src/rkcone/common/Makefile.am: object `Exception.lo' created > > > both with libtool and without > > [...] > > > I suspect there is an obvious solution to this that I am missing. Can > > > someone set a library building newbie on the right path here? =) > > [...] > > > > http://sources.redhat.com/ml/automake/2002-08/msg00128.html > > > > Unfortunateley I still fail to see how I can avoid the above problem. > Building a convenience library would seem to solve the problem, but if I > do that I am at the same place that I started this thread. Doing : > >librkcone_LDADD = common/libcommon.a > > is for some reason not a portable thing to do? To give you a little background: Objects which are included in shared libraries need to be compiled with -fPIC. Objects which are included in static libraries should be compiled without -fPIC. On i386, it is possible to include non-PIC code in a shared library; this does not work anywhere else, and it's slow on i386 anyway. A static or convenience library is usually built without -fPIC, so it can't be included in a shared library. It doesn't have to be, though. It would be possible for automake to build convenience libraries with -fPIC where necessary - it just doesn't. Actually, this might be hackable by stuffing -fPIC in the relevant CFLAGS variable - then the warning is spurious. -- .''`. ** 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?
On Mon, Jul 28, 2003 at 05:55:15PM -0500, Raja R Harinath wrote: > 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. No, there are about half a dozen files in po/ which aren't needed, and then there's all the m4 macros. -- .''`. ** 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?
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?
On Mon, Jul 28, 2003 at 11:39:48PM +0200, Alexandre Duret-Lutz wrote: > >>> "Andrew" == Andrew Suffield <[EMAIL PROTECTED]> writes: > > [...] > > > 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?
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: distribution signatures
On Wed, Jul 16, 2003 at 04:45:09AM -0400, Harlan Stenn wrote: > I'm trying to find a way to have automake generate Makefiles that will > automatically generate digital signatures for distributions, and trying to > figure out a good way to handle it. Not quite what you asked, but I just add this to my top-level Makefile.am: sign: gpg --detach-sign $(distdir).tar.gz md5sum $(distdir).tar.gz | gpg --clearsign > $(distdir).tar.gz.md5sum Then you make dist and/or distcheck as normal, and when you're ready to release, make sign. I don't see any particular reason why this is worth including in automake. It's trivial and will probably vary per project anyway. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | Dept. of Computing, `. `' | Imperial College, `- -><- | London, UK pgp0.pgp Description: PGP signature
Re: back quotes and double quotes must not be escaped?
On Mon, Nov 04, 2002 at 09:09:50AM +0100, Akim Demaille wrote: > | configure.ac:27: warning: back quotes and double quotes must not be escaped in: >$as_me:$LINENO: WARNING: \`$CC' requires \`$lt_cv_prog_cc_shlib' to build shared >libraries > | configure.ac:27: warning: back quotes and double quotes must not be escaped in: >$as_me: WARNING: \`$CC' requires \`$lt_cv_prog_cc_shlib' to build shared libraries > | configure.ac:27: warning: back quotes and double quotes must not be escaped in: >$as_me:$LINENO: WARNING: add \`$lt_cv_prog_cc_shlib' to the CC or CFLAGS env variable >and reconfigure > > This is not automake, but autoconf speaking. 2.55 will re-disable > this warning until Libtool has this fixed :( Sorry. This seems to be a common source of confusion. Would it be unrealistic to ask that autoconf/automake insert $0 into warning/error messages? Something like configure.ac:27: autoconf: warning: ... -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | Dept. of Computing, `. `' | Imperial College, `- -><- | London, UK msg06238/pgp0.pgp Description: PGP signature
