Re: managing autoconf versions?
Hello Jay, * On Thu, Jun 11, 2009 at 07:02:00AM + Jay wrote: [maybe should cc cygwin] Doing so. ;) For complete reference, I am citing your complete mail. As you do not seem to be subscribed, I am keeping you as a direct recipient, too. Just noticed your guys's responses, searching the web. Thanks. Spiro, I don't your answer of not including generating files with the patch suffices. - I think people do include them. I am doing open source projects myself. Whenever I get a patch where these generated files (auto*, bison, flex, ...) are included, I ask the sender to send a new copy without these files. There are really a pain in the ass! They are not worth the time it takes me to remove the patches. - It is important to match versions for testing purposes. If I test with a non matching autoconf/make, what they generate won't likely match, and that invalidates testing. In my experience, these differences are seldom important. If they are, I will take such a patch, of course. remaining parts left intact for reference on the ML Dave, thanks, it is exactly binutils/gcc I'm interested in. Thank you for proving I'm not crazy -- there really is a problem. Could be due to your work that cygwin is the best/easiest platform here (but so slow to fork. :( ). I was/am not aware of what the version macros achieve. You know, I mean...ignoring binutils/gcc, though they are relevant, would I install versions 1.1, 1.2, 1.3, etc. (made up versions) all to different prefix, put all the prefixes/bin in $PATH and the version macros search $PATH? Or do all the tools append versions to all their directories/files? You know, ideally..ideally what I would do is download every version of autoconf/automake configure and install them all with no flags put /usr/local/bin in $PATH and as long as I defined every correct/sufficient, be able to make arbitrary edits to arbitrary projects, and just run the usual configure+make on them and the right thing would happen. Or even, better yet, error if I don't have the matching version of autoconfigure/automake, perhaps guided by a flag one way or the other. - Jay Best regards, Spiro. -- Spiro R. Trikaliotis http://opencbm.sf.net/ http://www.trikaliotis.net/ http://www.viceteam.org/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: managing autoconf versions?
Spiro Trikaliotis wrote: Hello Jay, * On Thu, Jun 11, 2009 at 07:02:00AM + Jay wrote: remaining parts left intact for reference on the ML Dave, thanks, it is exactly binutils/gcc I'm interested in. Thank you for proving I'm not crazy -- there really is a problem. As your attorney, I advise you to take the fifth! Could be due to your work that cygwin is the best/easiest platform here (but so slow to fork. :( ). Ah, flattery. Actually, it's *bribery* that will get you everywhere, but a bit of flattery always helps the process along. I was/am not aware of what the version macros achieve. You know, I mean...ignoring binutils/gcc, though they are relevant, would I install versions 1.1, 1.2, 1.3, etc. (made up versions) all to different prefix, put all the prefixes/bin in $PATH and the version macros search $PATH? Or do all the tools append versions to all their directories/files? You know, ideally..ideally what I would do is download every version of autoconf/automake configure and install them all with no flags put /usr/local/bin in $PATH and as long as I defined every correct/sufficient, be able to make arbitrary edits to arbitrary projects, and just run the usual configure+make on them and the right thing would happen. Or even, better yet, error if I don't have the matching version of autoconfigure/automake, perhaps guided by a flag one way or the other. E have you ever actually looked at the selection of automake and autoconf packages in the cygwin distro? What we already have is largely what you describe above. cheers, DaveK -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
managing autoconf versions?
This is a little off topic. How do people manage autoconf/automake versions? In particular, I'm not doing my own work -- I could probably just install one recent version of everything and be ok. Rather I'm wondering about submitting patches to other projects, some projects might use one set of versions, or another. Change configure.ac/Makefile.am or such and regenerate configure/Makefile.in or such, using a matching toolset version so that churn is only what is desired? Is the solution to install to various custom prefix and tailor $PATH based on context? Or does one wrapper sniff the input or output and decide among the versions installed in a standard place? You know, like, input/or output could say # use autoconf 1.2.3 and then /usr/bin/autoconf could delegate to /usr/bin/autoconf-1.2.3 or such? Thanks, - Jay -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: managing autoconf versions?
Hello Jay, * On Sat, May 16, 2009 at 06:00:30AM + Jay wrote: How do people manage autoconf/automake versions? [...] Rather I'm wondering about submitting patches to other projects, Just make sure you do not include generated files in your patch, and you should be fine. Having the generated files in your patch would produce problems on the other side, regardless if you use the same version of auto* tools or not. HTH, Spiro. -- Spiro R. Trikaliotis http://opencbm.sf.net/ http://www.trikaliotis.net/ http://www.viceteam.org/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: managing autoconf versions?
Jay wrote: This is a little off topic. How do people manage autoconf/automake versions? GCC/binutils require specialised versions, and I keep them in a separate prefix, thanks to Chuck's gcc-tools-* packages, and add them to the front of $PATH when needed. For all other stuff, the automake/autoconf wrapper scripts that are part of the standard distro versions suffice to select a suitably-near match, at least in my experience. cheers, DaveK -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
