RE: maintainer mode
> -Original Message- > From: Roger Leigh [mailto:[EMAIL PROTECTED]] > Sent: Friday, April 12, 2002 6:05 AM Doing this allows us to > require only developers to have a greater set of tools to be > installed and configured, without passing on the burden to our users. Ditto for squid. We cannot expect all our users to have automake + autoconf on their system. After all, the entire point of configure scripts and make dist is that the toolkit doesn't need to be present on every system. Rob
make install doesn't?
Hi, I created some man3 docs and found that despite having added them to the man_MANS variable, they were not installed until I added: install : install-man3 RTFM is inadequate because it is such unexpected behavior. Especially considering the rule: > man3dir = $(mandir)/man3 > install-man3: $(man3_MANS) $(man_MANS) > @$(NORMAL_INSTALL) > $(mkinstalldirs) $(DESTDIR)$(man3dir) > @list='$(man3_MANS) $(dist_man3_MANS) $(nodist_man3_MANS)'; \ > l2='$(man_MANS) $(dist_man_MANS) $(nodist_man_MANS)'; \ > for i in $$l2; do \ > case "$$i" in \ > *.3*) list="$$list $$i" ;; \ > esac; \ > done; \ > for i in $$list; do \ > if test -f $(srcdir)/$$i; then file=$(srcdir)/$$i; \ > else file=$$i; fi; \ > ext=`echo $$i | sed -e 's/^.*\\.//'`; \ > inst=`echo $$i | sed -e 's/\\.[0-9a-z]*$$//'`; \ > inst=`echo $$inst | sed -e 's/^.*\///'`; \ > inst=`echo $$inst | sed '$(transform)'`.$$ext; \ > echo " $(INSTALL_DATA) $$file $(DESTDIR)$(man3dir)/$$inst"; \ > $(INSTALL_DATA) $$file $(DESTDIR)$(man3dir)/$$inst; \ > done It would seem that the "$(mkinstalldirs) $(DESTDIR)$(man3dir)" could be skipped if, in the end, $$list wound up empty -- Bruce Korb AG URL: http://autogen.sourceforge.net
Re: maintainer mode
Eric Siegerman wrote: > 4. The user imported your package into CVS (as I often do). > Because CVS checkouts are done in alphabetical order, foo.in > might well have a later timestamp than its corresponding foo, > without the files' content having changed. So the > maintainer-mode tests charge ahead and try to rebuild foo, > very probably with an incorrect version of the autotool in > question. Kaboom. See GCC's contrib/gcc_update. Or, my autogen/config/bootstrap. Or, several projects with misnamed "autogen.sh" scripts. None of these mess with weirdo --with-mumble options. :-) -- Bruce Korb AG URL: http://autogen.sourceforge.net
Re: maintainer mode
Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes: > Warning: I'm going to give the "AM_MAINTAINER_MODE is pure evil > on a stick" point of view. I know some people find it useful > (although I don't know when). I'm sure the reasons you gave are valid (and I was not aware of some of the downsides you mentioned), but I thought I would demonstrate a valid use for it. In the gimp-print source tree, there are a number of files which we ship in the distributed tarball pre-built. These are PDF and HTML versions of SGML manuals and PostScript versions of Texinfo manuals. We do not want an end-user to have to have these tools installed. The SGML tools are notoriously fragile (they are currently partly broken on my system!), and not all systems will have a teTeX installation. Maintainer mode is used to modify what is cleaned. If maint-mode is not enabled, then the pre-built files will never be cleaned. If it is used, by users who explicitly enable it, then they will be removed. Doing this allows us to require only developers to have a greater set of tools to be installed and configured, without passing on the burden to our users. Regards, Roger -- Roger Leigh ** Registration Number: 151826, http://counter.li.org ** Need Epson Stylus Utilities? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848 available on public keyservers
Re: maintainer mode
This is also the situation that occurs when checking out an older version of my software (using a CVS tag for example) to make a distribution. If timestamps are not just right automake/autoconf are required. And in general, the people that receive this software are not the least bit interested in modifying automake/autoconf files nor do they have the autotools installed (they are not using linux or cygwin). Without great care in aligning timestamps after each 'cvs commit' of configure.ac and configure, for example, the next 'cvs checkout' will produce a distribution that requires autotools. Is there are way to handle this other than AM_MAINTAINER_MODE? Eric Siegerman wrote: >On Thu, Apr 11, 2002 at 09:17:00PM +0200, Alexandre Duret-Lutz wrote: > >>Warning: I'm going to give the "AM_MAINTAINER_MODE is pure evil >>on a stick" point of view. >> > >>Now there are three cases: >> 1. The user unpacked your package, and then run ./configure and make. >>[...] >> 2. The user modified configure.ac, or Makefile.am, or a sibling. >>[...] >> 3. Your package is broken, it contains some files which are >>[...] >> > > 4. The user imported your package into CVS (as I often do). >Because CVS checkouts are done in alphabetical order, foo.in >might well have a later timestamp than its corresponding foo, >without the files' content having changed. So the >maintainer-mode tests charge ahead and try to rebuild foo, >very probably with an incorrect version of the autotool in >question. Kaboom. > >>Let's see what happens when AM_MAINTAINER_MODE is used: >> > > 4. The package just builds. > >-- > >| | /\ >|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] >| | / >"Outlook not so good." That magic 8-ball knows everything! >I'll ask about Exchange Server next. > - Anonymous > > >. >
Re: maintainer mode
This is also the situation that occurs when checking out an older version of my software (using a CVS tag for example) to make a distribution. If timestamps are not just right automake/autoconf are required. And in general, the people that receive this software are not the least bit interested in modifying automake/autoconf files nor do they have the autotools installed (they are not using linux or cygwin). Without great care in aligning timestamps after each 'cvs commit' of configure.ac and configure, for example, the next 'cvs checkout' will produce a distribution that requires autotools. Is there are way to handle this other than AM_MAINTAINER_MODE? Eric Siegerman wrote: [EMAIL PROTECTED]"> On Thu, Apr 11, 2002 at 09:17:00PM +0200, Alexandre Duret-Lutz wrote: Warning: I'm going to give the "AM_MAINTAINER_MODE is pure evilon a stick" point of view. Now there are three cases: 1. The user unpacked your package, and then run ./configure and make.[...] 2. The user modified configure.ac, or Makefile.am, or a sibling. [...] 3. Your package is broken, it contains some files which are[...] 4. The user imported your package into CVS (as I often do).Because CVS checkouts are done in alphabetical order, foo.inmight well have a later timestamp than its corresponding foo,without the files' content having changed. So themaintainer-mode tests charge ahead and try to rebuild foo,very probably with an incorrect version of the autotool inquestion. Kaboom. Let's see what happens when AM_MAINTAINER_MODE is used: 4. The package just builds.--| | /\|-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED]| | /"Outlook not so good." That magic 8-ball knows everything!I'll ask about Exchange Server next. - Anonymous.
Re: maintainer mode
On Thu, Apr 11, 2002 at 09:17:00PM +0200, Alexandre Duret-Lutz wrote: > Warning: I'm going to give the "AM_MAINTAINER_MODE is pure evil > on a stick" point of view. > Now there are three cases: > 1. The user unpacked your package, and then run ./configure and make. > [...] > 2. The user modified configure.ac, or Makefile.am, or a sibling. > [...] > 3. Your package is broken, it contains some files which are > [...] 4. The user imported your package into CVS (as I often do). Because CVS checkouts are done in alphabetical order, foo.in might well have a later timestamp than its corresponding foo, without the files' content having changed. So the maintainer-mode tests charge ahead and try to rebuild foo, very probably with an incorrect version of the autotool in question. Kaboom. > > Let's see what happens when AM_MAINTAINER_MODE is used: > 4. The package just builds. -- | | /\ |-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / "Outlook not so good." That magic 8-ball knows everything! I'll ask about Exchange Server next. - Anonymous
Re: maintainer mode
Warning: I'm going to give the "AM_MAINTAINER_MODE is pure evil on a stick" point of view. I know some people find it useful (although I don't know when). >>> "Chadwick" == Chadwick A McHenry <[EMAIL PROTECTED]> writes: [...] Chadwick> From the original thread (below) I get the impression Chadwick> that if automake and friends are on the users Chadwick> machine, and are not the same version as used by me Chadwick> (the developer), there could be 'trouble' due to Chadwick> ./configure testing for auto*. *Testing* for these tools will not break your build. Now there are three cases: 1. The user unpacked your package, and then run ./configure and make. Since all the configury files (configure, Makefile.in, config.h, etc.) are up-to-date w.r.t. their sources (configure.ac, Makefile.am, etc.) there is no need to rerun any of the auto* tools. So you checked for those tools but whether you find them or not isn't important since they are not used. This is the most common "user" case. 2. The user modified configure.ac, or Makefile.am, or a sibling. Obviously something needs to be regenerated to reflect these changes. Automake has added rules for this purpose in the Makefiles; these rules use the auto* tools found by configure. If these tools was not found, the "missing" script prints an error message so the user understand he needs them. 3. Your package is broken, it contains some files which are out-of-date w.r.t. their source. The user then get "missing" errors when they try to build. He reports them to you, and you fix your package. (I don't think it can happen if you use 'make distcheck'.) Let's see what happens when AM_MAINTAINER_MODE is used: 1. Just the same. 2. Running `make' after changing something doesn't update the dependencies. The user has to _know_ he should --enable-maintainer-mode, otherwise he will wonder why his changes have no effect (or worse: he won't notice they wasn't taken into account). 3. Although the package is broken (for instance configure doesn't reflect the content of configure.ac), the build will start anyway because the bug is *hidden*, and it may fail latter because of this non obvious configure/configure.ac mismatch. In the common case (1.) using AM_MAINTAINER_MODE changes nothing, in less usual cases (2., 3.) it just hides bugs when you forget to type --enable-maintainer-mode. (If you search the web for discussion about AM_MAINTAINER_MODE you will find some worth-reading rants from François Pinard on this topic, with some more philosophical points -- I'm sorry I don't have any pointer handy.) As far incompatibilities between different versions of these tools are concerned, this is unrelated to AM_MAINTAINER_MODE. If you have changed some source, you need the right tool to rebuilt it (and obviously you want the maintainer rules too). If however you touched nothing, you don't care about which versions you have. -- Alexandre Duret-Lutz
Re: maintainer mode (Was: Re: first time automaking question)
On Thu, 11 Apr 2002, Alexandre Duret-Lutz wrote: > >>> "Chadwick" == Chadwick A McHenry <[EMAIL PROTECTED]> writes: > Chadwick> Using AM_MAINTAINER_MODE seems to be a Good Thing, in > Chadwick> light of the potential problems for users, when it is > Chadwick> absent. Is there any reason I _would_not_ want to > Chadwick> include it in my configure.am and modify my bootstrap > Chadwick> script to specify '--enable-maintainer-mode'? > > What are the problems you want to hide with AM_MAINTAINER_MODE? > Maybe we can help you to fix them. > >From the original thread (below) I get the impression that if automake and friends are on the users machine, and are not the same version as used by me (the developer), there could be 'trouble' due to ./configure testing for auto*. I also read that these potentail problems are eliminated by adding AM_MAINTAINER_MODE. I haven't personally run this, but it seems like a good idea to eliminate the potential for any difficulty. On Thu, 11 Apr 2002, Steve M. Robbins wrote: > On Wed, Apr 10, 2002 at 02:15:24PM -0500, Sean Finney wrote: > > On Wed, Apr 10, 2002 at 09:34:48AM +0200, Alexandre Duret-Lutz wrote: > > > >>> "Sean" == Sean Finney <[EMAIL PROTECTED]> writes: > > > Sean> - ./configure now tests for auto* and makeinfo > > > > > > Sean> is that really necessary? > > > > > > Yes. Automake create Makefiles that know how to rerun the auto* > > > tools when necessary. So configure check for them. > > > > does this introduce any problems if the target machine doesn't > > have (or has ancient versions of) auto*? or, if the auto* isn't > > found, does it just not implement said functionality? > > Yes and no. You can run into trouble if the target machine has a > different version (older OR newer!) of autoconf or automake. Mostly > this is due to a badly-written macro which is, sadly, rather common. > ... > > You can completely disable these "maintainer rules" in the > *distributed* makefiles via the AM_MAINTAINER_MODE macro. Look it up > in the automake docs. > -- Chad McHenry Email: [EMAIL PROTECTED] Homepage: http://www.ccs.neu.edu/home/red AIM login: RockClimberRed
maintainer mode (Was: Re: first time automaking question)
>>> "Chadwick" == Chadwick A McHenry <[EMAIL PROTECTED]> writes: [...] Chadwick> Using AM_MAINTAINER_MODE seems to be a Good Thing, in Chadwick> light of the potential problems for users, when it is Chadwick> absent. Is there any reason I _would_not_ want to Chadwick> include it in my configure.am and modify my bootstrap Chadwick> script to specify '--enable-maintainer-mode'? What are the problems you want to hide with AM_MAINTAINER_MODE? Maybe we can help you to fix them. [...] -- Alexandre Duret-Lutz
I noticed your email -
Hi - I saw your email on a website I visited yesterday, and thought you might be interested in this. A few months back I joined a program and then...promptly forgot about it. You may have done this yourself sometime...you intend to work the program but then get caught in your day-to-day activities and it's soon forgotten. The program was free to join so maybe I just didn't take it very seriously. Anyway, near the end of May I received a letter from my sponsor (Vic Patalano) informing me that I had more than 2000 PAID members in my downline! As you can imagine, I was very skeptical. After all, how could I have more than 2000 paid members under me in a program that I had never promoted? I took the time to check out the site...then wrote to Vic asking for confirmation that these were paid members and not just free sign-ups...like me :) Well, it was true...I had 2365 paid members in my downline. This in a program that I had never worked! All I had to do was upgrade to a paid membership before the end of the month and I would have my position locked in and a downline of 2365 people. You can bet I wasted no time in getting my membership upgraded! I can tell you, if I had known what was happening with this program, I would have become an active paid member months ago! With this program, you will get a HUGE downline of PAID MEMBERS. My sponsor's check, which is a minimum of $5,000, arrives every month...on time. How would you like to lock your position in FREE while you check out this opportunity and watch your downline grow? You can join FREE: To sign up simply reply to: [EMAIL PROTECTED] Type in Subject: Send My FREE Membership (required) Type in Letter: Your First and Last Name (required) Your Email Address (if different from above) We will confirm your position and send you a special report as soon as possible, and also Your Free Member Number. I'll get you entered and let you know how you can keep track of your growing downline. That's all there's to it. I'll then send you info, and you can make up your own mind. Warm regards, Scott Johnson Trouble getting through on email? 207-832-0546 (24/7) P.S. After having several negative experiences with network marketing companies I had pretty much given up on them. This company is different--it offers value, integrity, and a REAL opportunity to have your own home-based business... and finally make real money on the internet. Don't pass this up..you can sign up and test-drive the program for FREE. All you need to do is get your free membership. 7157RuNk2-820evvO2374yHQa6-081l28
Re: first time automaking question
On Thu, 11 Apr 2002, Steve M. Robbins wrote: > On Wed, Apr 10, 2002 at 02:15:24PM -0500, Sean Finney wrote: > > On Wed, Apr 10, 2002 at 09:34:48AM +0200, Alexandre Duret-Lutz wrote: > > > >>> "Sean" == Sean Finney <[EMAIL PROTECTED]> writes: > > > Sean> - ./configure now tests for auto* and makeinfo > > > > > > Sean> is that really necessary? > > > > > > Yes. Automake create Makefiles that know how to rerun the auto* > > > tools when necessary. So configure check for them. > > > > does this introduce any problems if the target machine doesn't > > have (or has ancient versions of) auto*? or, if the auto* isn't > > found, does it just not implement said functionality? > > Yes and no. You can run into trouble if the target machine has a > different version (older OR newer!) of autoconf or automake. Mostly > this is due to a badly-written macro which is, sadly, rather common. > ... > > You can completely disable these "maintainer rules" in the > *distributed* makefiles via the AM_MAINTAINER_MODE macro. Look it up > in the automake docs. > Using AM_MAINTAINER_MODE seems to be a Good Thing, in light of the potential problems for users, when it is absent. Is there any reason I _would_not_ want to include it in my configure.am and modify my bootstrap script to specify '--enable-maintainer-mode'? This macro seems misnamed to me. I'm thinking that generating the auto* rules _is_ a maintainer mode, as they are potentially dangerous/confusing to the end user. If they are generated by default, and to disable generating them (without explicitly asking for them) one should use a rule named 'AM_DISABLE_MAINTAINER_MODE' or something similar. Chalk this up to 'historic reasons'? ...Chad
Re: first time automaking question
On Wed, Apr 10, 2002 at 02:15:24PM -0500, Sean Finney wrote: > On Wed, Apr 10, 2002 at 09:34:48AM +0200, Alexandre Duret-Lutz wrote: > > >>> "Sean" == Sean Finney <[EMAIL PROTECTED]> writes: > > Sean> - ./configure now tests for auto* and makeinfo > > > > Sean> is that really necessary? > > > > Yes. Automake create Makefiles that know how to rerun the auto* > > tools when necessary. So configure check for them. > > does this introduce any problems if the target machine doesn't > have (or has ancient versions of) auto*? or, if the auto* isn't > found, does it just not implement said functionality? Yes and no. You can run into trouble if the target machine has a different version (older OR newer!) of autoconf or automake. Mostly this is due to a badly-written macro which is, sadly, rather common. However, if *no* autotools are detected, updating the Makefile.in or configure file just doesn't happen, as you suspected. You can completely disable these "maintainer rules" in the *distributed* makefiles via the AM_MAINTAINER_MODE macro. Look it up in the automake docs. -S -- by Rocket to the Moon, by Airplane to the Rocket, by Taxi to the Airport, by Frontdoor to the Taxi, by throwing back the blanket and laying down the legs ... - They Might Be Giants
Re: automake reports .lo file created with and without libtool
>>> "Skip" == Skip Montanaro <[EMAIL PROTECTED]> writes: [...] Skip> check_PROGRAMS = alftest Skip> alftest_SOURCES = alftest.c Skip> alftest_LDADD = ../src/libalf.a Skip> I want the test program linked with the static library in Skip> the build tree to avoid inadvertently linking with any Skip> previously installed shared libraries, so I explicitly Skip> mentioned the .a file. Skip> The .a file isn't getting built if I run "make" or "make Skip> check". The reason I didn't notice it before was that Skip> "make distclean" doesn't delete the static library Skip> without the build lines in Makefile.am. Skip> For now it looks like I will have to add the static Skip> library build lines back to src/Makefile.am and put up Skip> with the warning message from automake. Any suggestions Skip> about alternative approaches would be gladly received. Either change alftest_LDADD = ../src/libalf.a to alftest_LDADD = ../src/libalf.la This means alftest will be linked against libalf.so or libalf.a depending on what have been built (the user can disable static or shared libraries using --disable-static or --disable-shared), It seems to me this is what you try to avoid. Or keep the definition for both libraries, and try the workaround I mentioned: libalf_a_CFLAGS = $(AM_CFLAGS) My limitied testing shows this is enough to suppress the warning. -- Alexandre Duret-Lutz
RE: Large project support
> -Original Message- > From: Timo K Suoranta [mailto:[EMAIL PROTECTED]] > Sent: Thursday, April 11, 2002 5:41 PM > > > Wildcards are unreliable, and with automake we try to > promote reliable > > builds. For instance that is why we use full instead of partial > > dependency information. > > Wildcards can be unrealiable if you don't spesifically > indicate that you want them, and that you really knbw that > your source directories must only contain files that really > belong to that project. > > However, manual editing of source file list is not much more > reliable I think. > > > As an example suppose you want to use per-executable CFLAGS. This > > feature won't work with wildcards since we must generate an > explicit > > rule for each .o in the executable. > > Per-executable CFLAGS can be done by having per-directory > CFLAGS. I already place each executable sources to separate directory. Or simply allow a patternmatch. If you can pattern match what .c and .cc files go into foo[.exe], surely one can do the same thing for CFLAGS. Rob
Automake 1.6.1 release.
We're pleased to announce the release of Automake 1.6.1. This is a bug fix release, and as such there is no new features since Automake 1.6. The NEWS entry is appended. You can find the new release here: ftp://ftp.gnu.org/gnu/automake/automake-1.6.1.tar.gz ftp://ftp.gnu.org/gnu/automake/automake-1.6.1.tar.bz2 ftp://sources.redhat.com/pub/automake/automake-1.6.1.tar.gz ftp://sources.redhat.com/pub/automake/automake-1.6.1.tar.bz2 Soon it will also appear on the sources and GNU mirrors. Follow these links for a list of them: http://www.gnu.org/order/ftp.html http://sources.redhat.com/mirrors.html - Akim, Alexandre, and Tom New in 1.6.1: * automake --output-dir is deprecated * Many bug fixes, including: - Don't choke on AM_LDFLAGS definitions. - Clean libtool objects from subdirectories. - Allow configure variables with reserved suffix and unknown prefix (e.g. AC_SUBST(mumble_LDFLAGS) when 'mumble' is not a target). - Fix the definition of AUTOMAKE and ACLOCAL in configure.
Re: Large project support
> Wildcards are unreliable, and with automake we try to promote reliable > builds. For instance that is why we use full instead of partial > dependency information. Wildcards can be unrealiable if you don't spesifically indicate that you want them, and that you really knbw that your source directories must only contain files that really belong to that project. However, manual editing of source file list is not much more reliable I think. > As an example suppose you want to use per-executable CFLAGS. This > feature won't work with wildcards since we must generate an explicit > rule for each .o in the executable. Per-executable CFLAGS can be done by having per-directory CFLAGS. I already place each executable sources to separate directory. > With wildcards there is no way to know when we need to regenerate the > Makefile (we could do it every time, but first that would be horrible > and people would complain, and second it only works with GNU make > anyway). I would be happy with something that I can call manually. I would have to edit Makefile.am's manually anyaway - I just would like to say something like autome --update instead. I would happily wait the time running autotools takes. The wildcard pass is not the significant part of this rerun. You do not need GNU make to make a list of source files when this is done as part of automake pass. My project currently has over 260 files in 20 directories and around 5 lines of source code. The automake --update feature, or a simple script which I could run before running automake, would be useful simply to create the Makefile.am files - I am sure you can imagine that :) -- Timo Suoranta -- [EMAIL PROTECTED] --
