Re: debbugs, and a FAQ, for Autotools
Hello Ralf, * Ralf Hemmecke wrote on Tue, Feb 22, 2011 at 10:30:21PM CET: I'm just reading the current FAQ under 1.3 Where can I get the latest versions of these tools? http://www.gnu.org/software/automake/faq/autotools-faq.html#Where-can-I-get-the-latest-versions-of-these-tools_003f Wouldn't it be useful to give a little script that installs know-good combinations (the latest version?) of all the autotools components in the users (developers) HOME? You probably can do https://github.com/hemmecke/flint2/blob/autotools/autotools.mk better than me, but it might be a first start. Well, http://www.gnu.org/software/automake/faq/autotools-faq.html#How-do-I-install-the-Autotools-_0028as-user_0029_003f is not as cool as your version, but provides roughly the same functionality AFAICS. I think either of these two improvements would be nice: - having a list of known-good combinations of tool versions; having tested them extensively would be great, otherwise we might at least document some sort of minimal-version-requirement-table. - a change that lets the script automatically install the most recent stable releases of each tool. Cheers, Ralf
Re: debbugs, and a FAQ, for Autotools
Hello, * Miles Bader wrote on Wed, Feb 23, 2011 at 05:17:29AM CET: Ralf Hemmecke writes: Sure. But it is also relevant if one developer adds a macro which is only available in some recent version of automake, say. Another developer might not yet have that automake version. It doesn't really seem any worse than _any_ potential tool incompatibility problem -- compiler version, library version, etc -- though... Usually those issues aren't such a huge deal, because most project try to be relatively portable, and when version dependencies do crop up, they can be dealt with relatively well using simple checks in the configure script. Isn't that what people usually do about autoconf versions too (declare a minimum version in configure.ac)? Yes. You can even declare a maximum (or exact) version, too, if that is what you need. We did that in GCC, see the _GCC_AUTOCONF_VERSION_CHECK macro in http://gcc.gnu.org/viewcvs/trunk/config/override.m4?view=markup and with Automake, it should work at least to test $am__api_version at configure time. I guess we should make it possible to test easily at m4 run time too ... (and I guess this is worth another FAQ entry ...) Cheers, Ralf
Re: debbugs, and a FAQ, for Autotools
Sure. But it is also relevant if one developer adds a macro which is only available in some recent version of automake, say. Another developer might not yet have that automake version. It doesn't really seem any worse than _any_ potential tool incompatibility problem -- compiler version, library version, etc -- though... Usually those issues aren't such a huge deal, because most project try to be relatively portable, and when version dependencies do crop up, they can be dealt with relatively well using simple checks in the configure script. Isn't that what people usually do about autoconf versions too (declare a minimum version in configure.ac)? Yes. You can even declare a maximum (or exact) version, too, if that is what you need. We did that in GCC, see the _GCC_AUTOCONF_VERSION_CHECK macro in http://gcc.gnu.org/viewcvs/trunk/config/override.m4?view=markup and with Automake, it should work at least to test $am__api_version at configure time. I guess we should make it possible to test easily at m4 run time too ... Fine, but do you expect every developer to be able to write good m4 macros? Or search the Internet for macros that could be relevant for ones own project? I know projects where people (mis-)use autotools even if their project is not fitting in a standard C project, just to gain a bit more portability and achieve standard makefile targets where otherwise most developers would program in a project specific langauge. Is there actually a good reason, why the autotools are distributed as separate packages (autoconf, automake, libtool, m4)? (Maybe even pkg-config, but I still don't yet know exactly whether it is good for me.) Nowadays, it's certainly not a question of diskstorage anymore and it would probably ease autotools acceptance if there were just one software to install. (Just a suggestion.) (and I guess this is worth another FAQ entry ...) Definitely. Ralf
Re: debbugs, and a FAQ, for Autotools
On 02/23/2011 05:02 PM, Ben Pfaff wrote: The question libtool reorders link fags seems to have a spelling error in the last word. It's not obvious to me what word is meant. flags -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: debbugs, and a FAQ, for Autotools
* Eric Blake wrote on Thu, Feb 24, 2011 at 01:04:31AM CET: On 02/23/2011 05:02 PM, Ben Pfaff wrote: The question libtool reorders link fags seems to have a spelling error in the last word. It's not obvious to me what word is meant. flags Fixed now, thanks for the report. Ralf
Re: debbugs, and a FAQ, for Autotools
Ralf Hemmecke hemme...@gmail.com writes: Is there actually a good reason, why the autotools are distributed as separate packages (autoconf, automake, libtool, m4)? (Maybe even pkg-config, but I still don't yet know exactly whether it is good for me.) Hmm, why not? Isn't it good general practice to split up packages where the coupling is fairly loose? Many people use autoconf without automake, and the latter has some significant extra dependencies. Also, of course, libtool is extremely optional (and for those that do use it, I imagine it would work well enough without the rest of the autotools). -miles -- Egotist, n. A person of low taste, more interested in himself than in me.
Re: debbugs, and a FAQ, for Autotools
I'm just reading the current FAQ under 1.3 Where can I get the latest versions of these tools? http://www.gnu.org/software/automake/faq/autotools-faq.html#Where-can-I-get-the-latest-versions-of-these-tools_003f Wouldn't it be useful to give a little script that installs know-good combinations (the latest version?) of all the autotools components in the users (developers) HOME? You probably can do https://github.com/hemmecke/flint2/blob/autotools/autotools.mk better than me, but it might be a first start. I suggest this, because I heard several rumours that autotools are a nightmare and developers might have different versions of them installed thus leading to weird behaviour. I just think that providing such a script would contribute to the acceptance of autotools outside the GNU world. That Linux distributions usually come with a good set of autotools is irrelevant, since in my understanding all developers of *one* project should work with the *same* autotools versions. Of course, the project might also compile otherwise on different systems, but using the same version of autotools everywhere reduces (needless) incompatibility issues between developers and increases acceptance of autotools. No? Ralf
Re: debbugs, and a FAQ, for Autotools
http://www.gnu.org/software/automake/faq/autotools-faq.html#How-do-I-add-a-question-to-this-FAQ_003f Do you think, it would be a good idea to just open up a git repo (on github.com, for example) and put the autotools-faq.texi file there? Or is there already a git repo for this? Ralf
Re: debbugs, and a FAQ, for Autotools
On 02/22/2011 11:35 PM, Paul Smith wrote: On Tue, 2011-02-22 at 22:30 +0100, Ralf Hemmecke wrote: That Linux distributions usually come with a good set of autotools is irrelevant, since in my understanding all developers of *one* project should work with the *same* autotools versions. Of course, the project might also compile otherwise on different systems, but using the same version of autotools everywhere reduces (needless) incompatibility issues between developers and increases acceptance of autotools. No? This is very important IF you check in the outputs of the autotools into your source repository. Sure. But it is also relevant if one developer adds a macro which is only available in some recent version of automake, say. Another developer might not yet have that automake version. I'm all in favour of considering files generated by autotools as object file which should not go into your favourite VCS. But different projects have different needs. Some might require skills that are not in the realm of C programming. For such projects it might me more natural to relieve their contributors from dealing (or even installing) autotools. But anyway, if a project, comes with a small (and portable) script like actually given on http://www.gnu.org/software/automake/faq/autotools-faq.html#How-do-I-install-the-Autotools-_0028as-user_0029_003f no developer (whether interested in autotools or not) should fear installation of the autotools, because all will basically happen in the background. Ralf
Re: debbugs, and a FAQ, for Autotools
On Tue, 2011-02-22 at 22:30 +0100, Ralf Hemmecke wrote: That Linux distributions usually come with a good set of autotools is irrelevant, since in my understanding all developers of *one* project should work with the *same* autotools versions. Of course, the project might also compile otherwise on different systems, but using the same version of autotools everywhere reduces (needless) incompatibility issues between developers and increases acceptance of autotools. No? This is very important IF you check in the outputs of the autotools into your source repository. If you do that, and people use different versions of autotools, then you're constantly getting a ping-pong effect with these files as different developers check in different versions. My opinion has always been that those are object files, not source files, and just as you'd not typically check in a .o into your source repository, so you wouldn't check in the output of autotools. Because of that it doesn't matter to me which version of autotools other people use. The downside of the approach I use is that anyone who wants to build from the source repository has to go get copies of the autotools and install them first. I prefer this option anyway, as I think developers need those tools, but other teams may have other preferences.
Re: debbugs, and a FAQ, for Autotools
Ralf Hemmecke hemme...@gmail.com writes: Sure. But it is also relevant if one developer adds a macro which is only available in some recent version of automake, say. Another developer might not yet have that automake version. It doesn't really seem any worse than _any_ potential tool incompatibility problem -- compiler version, library version, etc -- though... Usually those issues aren't such a huge deal, because most project try to be relatively portable, and when version dependencies do crop up, they can be dealt with relatively well using simple checks in the configure script. Isn't that what people usually do about autoconf versions too (declare a minimum version in configure.ac)? -Miles -- Rational, adj. Devoid of all delusions save those of observation, experience and reflection.
Re: debbugs, and a FAQ, for Autotools
* Ralf Hemmecke wrote on Tue, Feb 22, 2011 at 10:41:20PM CET: http://www.gnu.org/software/automake/faq/autotools-faq.html#How-do-I-add-a-question-to-this-FAQ_003f Do you think, it would be a good idea to just open up a git repo (on github.com, for example) and put the autotools-faq.texi file there? Or is there already a git repo for this? Maybe. It is currently in the web pages CVS, so an export from there wouldn't be hard either. The savannah page for automake shows how to access the CVS (a patch to add that bit of info to the FAQ would be welcome ;-) I'm not sure if git is needed here (other than that it of course would be nice if all webpage stuff was in git anyway), since I hope we don't need diverging or long-time developments in the FAQ. ;-) Thanks, Ralf
Re: debbugs, and a FAQ, for Autotools
On 02/13/2011 11:12 AM, Ralf Wildenhues wrote: [ Cross post; Reply-To and Mail-Followup-To set. Please followup to the automake list only, to avoid excessive spammage. Thank you. ] Hello everyone, I've been advertising debbugs before, I think we should be a good example. So, two proposals: 1) Autoconf and Libtool should also use debbugs. bug-automake has switched a few months ago, and I find it helpful to avoid losing reports. Given that we never have enough time on our hands, it becomes more important to not lose track. See http://debbugs.gnu.org/ and linked pages for details. Seems like it might be reasonable for autoconf. However, my biggest concern is that right now, I filter both autoconf and automake messages into the same mail folder, but debbugs anonymizes which list a bug is being reported against (that is, the To: is rewritten as ###@debbugs.gnu.org, so there is no longer any mention of 'automake' in any of the normal mail headers). While I could probably force filtering to take place on X-Debbugs-Original-To:, that still doesn't solve the problem of no visual indication on which list a bug is reported against. Any ideas on how to resolve that issue? -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: debbugs, and a FAQ, for Autotools
Hi Eric, * Eric Blake wrote on Mon, Feb 21, 2011 at 03:24:01PM CET: On 02/13/2011 11:12 AM, Ralf Wildenhues wrote: 1) Autoconf and Libtool should also use debbugs. bug-automake has switched a few months ago, and I find it helpful to avoid losing reports. Given that we never have enough time on our hands, it becomes more important to not lose track. See http://debbugs.gnu.org/ and linked pages for details. Seems like it might be reasonable for autoconf. However, my biggest concern is that right now, I filter both autoconf and automake messages into the same mail folder, but debbugs anonymizes which list a bug is being reported against (that is, the To: is rewritten as ###@debbugs.gnu.org, so there is no longer any mention of 'automake' in any of the normal mail headers). While I could probably force filtering to take place on X-Debbugs-Original-To:, that still doesn't solve the problem of no visual indication on which list a bug is reported against. Can you show Sender: information by your mail program? That's what I use both for show and filter. This seems like a problem that is more general than just the question of whether Autoconf or Libtool should use debbugs. IOW, if the above is not sufficient, then debbugs should provide help. (Or we could also patch mail user agents. ;-) I'm adding Glenn in Cc:, in case he has further input on this. Thanks, Ralf
Re: debbugs, and a FAQ, for Autotools
However, my biggest concern is that right now, I filter both autoconf and automake messages into the same mail folder, but debbugs anonymizes which list a bug is being reported against (that is, the To: is rewritten as ###@debbugs.gnu.org, so there is no longer any mention of 'automake' in any of the normal mail headers). There is an X-GNU-PR-Package: header that you can filter on, or configure your mail client to display by default. Or, you will still receive the messages via the appropriate mailing list, so there will be the standard List-Id etc headers. But no, there is no indication that is visible by default if you have chosen to put two mailing lists into the same folder. Maybe you could turn on the Mailman subject_prefix option for your lists? (It was a deliberate change to make it rewrite the To: header. After about a year of using it for Emacs without that change, it was a frequent occurence that people were either replying to both ###@debbugs and bug-gnu-emacs, thus creating a bunch of pointless duplicate mails, or replying to just bug-gnu-emacs, and somehow creating a new bug report, which was even more annoying.)
Re: debbugs, and a FAQ, for Autotools
Glenn Morris wrote (on Mon, 21 Feb 2011 at 16:08 -0500): Maybe you could turn on the Mailman subject_prefix option for your lists? Actually, that might interfere with how debbugs recognizes replies to existing bug reports that get sent to eg bug-automake rather than ###@debbugs. It might cause these to generate new bug reports.
Re: debbugs, and a FAQ, for Autotools
Hello everyone, * Ralf Wildenhues wrote on Sun, Feb 13, 2011 at 07:12:02PM CET: 2) Autotools should have a FAQ document. I've done a brain dump now, here's a rough initial version: http://www.gnu.org/software/automake/faq/autotools-faq.html and http://www.gnu.org/software/automake/faq/autotools-faq.texi (the former is generated from the latter via the Makefile). It is all incomplete, buggy, partly ugly, probably missing gnulib and gettext references in places, and everything, but I would like something to point users to now. Should all be reformulated nicely eventually ... I'd be happy about feedback, help, anything. For now there are several more questions than answers, and there are certainly many more questions that you can think of, so please write them. I don't actually care about the license, as long as we can move text between FAQ and manuals without too much hassle. Thanks, Ralf
Re: debbugs, and a FAQ, for Autotools
Hi Russell, * Russell Shaw wrote on Mon, Feb 14, 2011 at 12:00:14AM CET: I'd ask more about how the internals of ./configure and autoconf works. Can you formulate more specific questions? And questions on how to make bison get handled without being forced to mimic standard yacc. I've added that question there now (without answer so far). Thanks, Ralf
Re: debbugs, and a FAQ, for Autotools
On 20/02/11 06:10, Ralf Wildenhues wrote:
Hi Russell,
* Russell Shaw wrote on Mon, Feb 14, 2011 at 12:00:14AM CET:
I'd ask more about how the internals of ./configure and autoconf works.
Can you formulate more specific questions?
And questions on how to make bison get handled without being forced to
mimic standard yacc.
I've added that question there now (without answer so far).
Thanks,
Ralf
Hi,
I'm not in autoconf debugging mode atm, so i'll have to ask more detailed
things some other time.
Looking through a ./configure script, i see lots of things being done
with file descriptors 5 and 6. What is going on here? eg:
## ##
## Autoconf initialization. ##
## ##
# ac_fn_c_try_compile LINENO
# --
# Try to compile conftest.$ac_ext, and return whether this succeeded.
ac_fn_c_try_compile ()
{
as_lineno=${as_lineno-$1} as_lineno_stack=as_lineno_stack=$as_lineno_stack
rm -f conftest.$ac_objext
if { { ac_try=$ac_compile
case (($ac_try in
*\* | *\`* | *\\*) ac_try_echo=\$ac_try;;
*) ac_try_echo=$ac_try;;
esac
eval ac_try_echo=\\$as_me:${as_lineno-$LINENO}: $ac_try_echo\
$as_echo $ac_try_echo; } 5
(eval $ac_compile) 2conftest.err
ac_status=$?
if test -s conftest.err; then
grep -v '^ *+' conftest.err conftest.er1
cat conftest.er1 5
mv -f conftest.er1 conftest.err
fi
$as_echo $as_me:${as_lineno-$LINENO}: \$? = $ac_status 5
test $ac_status = 0; } {
test -z $ac_c_werror_flag ||
test ! -s conftest.err
} test -s conftest.$ac_objext; then :
ac_retval=0
else
$as_echo $as_me: failed program was: 5
sed 's/^/| /' conftest.$ac_ext 5
ac_retval=1
fi
eval $as_lineno_stack; test x$as_lineno_stack = x { as_lineno=; unset
as_lineno;}
as_fn_set_status $ac_retval
} # ac_fn_c_try_compile
Re: debbugs, and a FAQ, for Autotools
On 14/02/11 05:12, Ralf Wildenhues wrote: [ Cross post; Reply-To and Mail-Followup-To set. Please followup to the automake list only, to avoid excessive spammage. Thank you. ] Hello everyone, I've been advertising debbugs before, I think we should be a good example. So, two proposals: 1) Autoconf and Libtool should also use debbugs. bug-automake has switched a few months ago, and I find it helpful to avoid losing reports. Given that we never have enough time on our hands, it becomes more important to not lose track. See http://debbugs.gnu.org/ and linked pages for details. 2) Autotools should have a FAQ document. Not of the sort of the FAQ chapter that answers seven random questions and that has a 1 year+ latency until it is updated, but one that answers both totally-newbie kinds of questions that get asked over and over again, or cross-tool bug questions like the infamous libtool echo problem (which was due to an incompatible m4sugar change). A document that, ideally, eventually obsoletes many of the third-party here's how autotools work, in quick kinds of pages. See e.g., this most recent thread which made the need so clear again: http://thread.gmane.org/gmane.comp.sysutils.automake.patches/5672 For (2) I'd suggest a wiki if we GNU the infrastructure, but something like a new page http://www.gnu.org/software/automake/Autotools-FAQ.html would certainly be good. (And yes, I've been arguing against wikis in the past. I was wrong. Sue me.) Now, I have very little spare time on my hands. Any volunteers on managing such a document? Any people interested in contributing answers or even only questions? I wouldn't mind handing out commit privs to any of the regulars on these lists. I'd ask more about how the internals of ./configure and autoconf works. And questions on how to make bison get handled without being forced to mimic standard yacc. I'm not in the mode of autoconf hacking atm though.
