From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Sat, 12 Oct 2002 04:39:17 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 343 ************************************************** Friday 11 October 2002 Number 343 ************************************************** Subjects for today 1 Re: Latest version of autoconf? : Jeff Robinson 2 Re: Latest version of autoconf? : John Poltorak 3 Re: Latest version of autoconf? : Andreas Buening **= Email 1 ==========================** Date: Sat, 12 Oct 2002 07:23:34 -0500 From: Jeff Robinson Subject: Re: Latest version of autoconf? John Poltorak wrote: > On Fri, Oct 11, 2002 at 05:04:23PM -0500, Jeff Robinson wrote: > >>I upgraded to make 3.79.2a1 and everything went fine. I've now got a >>functioning autoconf! >> >>Just as an aside, you mentioned that the reason to go through these >>steps is that the autoconf scripts have their paths coded into them. If >>one were to try distributing this with an installer, would it be >>possible to do the install and then use sed to replace the existing >>paths in the scripts with the proper ones? (I haven't checked yet, I'm >>just looking for an off-the-cuff answer). > > > The whole pointing of building Autoconf rather than just extracting an > archive is that you can specify those embedded paths for yourself and > tailor them to your own environment. The GNU build system is not designed > for jumping through hoops and running arbitrary sed scripts here and > there. Everything is set up for you to get it as you want it in the first > place. You can run:- > > sh configure --help > > to see a list of the available options. > The reason that I asked is that in trying to trying to compile a few different sets of source code I find that I'm spending far more time trying to get all the tools configured than working on my projects. I am in no way implying that configuring things from the ground-up is wrong or bad, just a different way of going about things for those that want the control. I was conceptually trying to figure out how one could do an install from a "package" but have it work for their system. Autoconf 2.13 only required the setting of two environmental variables for it to work correctly on my system. (Though Andreas apparently didn't meet with the same success, so the way 2.13 works has been proven fallible). I thought that there must be a way to accomplish this end as you can download a Slackware pkg of Autoconf and install it without the support-tools needed to get it up and running (not that it would do one much good). Though by default as well Slackware packages are setup to be in the proper place as far as the filesystem heirarchy goes... I have no idea what happens if you specify the --target_dir option of pkgtool and try to install it. (And frankly, my Linux systems work just fine so I'm not too intrigued by the idea of messing them up). Right now I'm on a "fact-finding" mission to see if some of these things can be done in a more painless way (from my POV). I appreciate any feedback, though. Thanks, Jeff -- ---------------- Whatza JamochaMUD? http://jamochamud.anecho.mb.ca Or other stuff: http://www.anecho.mb.ca/~jeffnik ----------------------------------------------------------- **= Email 2 ==========================** Date: Sat, 12 Oct 2002 12:18:55 +0100 From: John Poltorak Subject: Re: Latest version of autoconf? On Fri, Oct 11, 2002 at 05:04:23PM -0500, Jeff Robinson wrote: > > I upgraded to make 3.79.2a1 and everything went fine. I've now got a > functioning autoconf! > > Just as an aside, you mentioned that the reason to go through these > steps is that the autoconf scripts have their paths coded into them. If > one were to try distributing this with an installer, would it be > possible to do the install and then use sed to replace the existing > paths in the scripts with the proper ones? (I haven't checked yet, I'm > just looking for an off-the-cuff answer). The whole pointing of building Autoconf rather than just extracting an archive is that you can specify those embedded paths for yourself and tailor them to your own environment. The GNU build system is not designed for jumping through hoops and running arbitrary sed scripts here and there. Everything is set up for you to get it as you want it in the first place. You can run:- sh configure --help to see a list of the available options. > Jeff > > -- > ---------------- > Whatza JamochaMUD? > http://jamochamud.anecho.mb.ca > > Or other stuff: http://www.anecho.mb.ca/~jeffnik > ----------------------------------------------------------- -- John **= Email 3 ==========================** Date: Sat, 12 Oct 2002 14:57:54 +0200 From: Andreas Buening Subject: Re: Latest version of autoconf? John Poltorak wrote: > > On Fri, Oct 11, 2002 at 05:04:23PM -0500, Jeff Robinson wrote: > > > > I upgraded to make 3.79.2a1 and everything went fine. I've now got a > > functioning autoconf! > > > > Just as an aside, you mentioned that the reason to go through these > > steps is that the autoconf scripts have their paths coded into them. If > > one were to try distributing this with an installer, would it be > > possible to do the install and then use sed to replace the existing > > paths in the scripts with the proper ones? (I haven't checked yet, I'm > > just looking for an off-the-cuff answer). In principle, yes. For the final replacement you could use a sed script. However, it should be more sophisticated than "sed -e s,c:,$UNIXROOT,g". And the preparation program (before you can put the "compiled" autoconf into a zip file) needs some maintainer assistance to decide which files have to be considered (e.g. it makes no sense to modify drive letters in the doc files). > The whole pointing of building Autoconf rather than just extracting an > archive is that you can specify those embedded paths for yourself and > tailor them to your own environment. The GNU build system is not designed > for jumping through hoops and running arbitrary sed scripts here and > there. Everything is set up for you to get it as you want it in the first > place. You can run:- > > sh configure --help > > to see a list of the available options. With these options you can configure autoconf only for _your_ system. autoconf then might find its files in c:/usr/share/autoconf but not in d:/usr/share/autoconf if c: is your and d: is my UNIXROOT. And all paths determined at compile time like c:/usr/bin/m4.exe or c:/usr/bin/perl.exe won't exist on other people's computer. bye, Andreas -- One OS to rule them all, One OS to find them, One OS to bring them all and in the darkness bind them In the Land of Mordor where the Shadows lie.