Re: automake parallel install
Tom Tromey <[EMAIL PROTECTED]> writes: > > "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes: > > Tom> My current thinking is that we would name the installed version > Tom> and the install directories after the "install version". For > Tom> anything in the 1.5 series (1.5.1, 1.5-p1, 1.5c, whatever), this > Tom> would be "1.5". Then we would guarantee that for a given > Tom> "install version" we would only do bug fixes. > > I decided not to do this. It is simpler and easier to understand if > we simply always add the version number. You mean install /usr/bin/automake-1.5.1p5? I don't understand quite how it works then. How do I use a specific version of automake in my script or spec file? People can manage a new ABI from time to time (automake-1.4, automake-1.5) but thinking about every possible automake bugfix release is kind of overboard. Are you really going to break compatibility with every bugfix release? If not, why shouldn't all compatible releases be interchangeable? Why would I want to install 10 bugfix-only releases in parallel? That is, it makes sense to put "automake-1.5" in a script or spec file, but not to put "automake-1.5.1p5" in there because it'll change with annoying frequency and the micro version is not relevant, only the "ABI version." Adding ".1p5" is like bumping the soname without changing the ABI, resulting in zillions of pointless copies of the interface. Installing 1.4, 1.5, and 1.6 is pretty sane, installing all bugfix releases is nuts. ;-) The idea is that whenever users of a tool expect a specific interface, they should invoke a command name that represents exactly the set of tool versions that support that interface, neither more nor less. BTW I wrote up a general discussion of the parallel install problem: http://pobox.com/~hp/parallel.html This is mostly about libraries though. Havoc
Professional Optical Manufacturer
Hi, Dear Sir, Nantong Yudi Optical Instrument Co.,Ltd is a Manufacturer Specilized in All Kinds of Optical Glass Lens, Having The Twenty-Year Manufacturing Experience, Gaining Certificate Of QSM ISO9002. Our Main Products Are Included Large, Middium And Small Size Spherical Lens (2mm-250mm), Plano Lens, Prism, Condensing Aspherical Lens, Door-Lens, Rifle-Scope, CMOS Lens, CCD Lens, Collimating Lens, Projecting Lens, Cylinder Lens And Optical Blanks,etc. The Professional Optical Manufacturer, The Best products and Lowest price. OEM/ODM are welcomed. To find out more information, Please visit our web site at: http://www.yudi.com.cn If you are any question, freely contact: [EMAIL PROTECTED] Powered By www.optoelectro.com
bug with unrecognized options
Akim et al -- The perl getopt package leaves something to be desired in its error output. Compare: creche. automake --zardoz Unknown option: zardoz creche. cp --zardoz cp: unrecognized option `--zardoz' Try `cp --help' for more information. I much prefer the cp output. For one thing it is more "GNUish". Is it difficult to fix this? Tom
Re: automake parallel install
> "Ralf" == Ralf Corsepius <[EMAIL PROTECTED]> writes: Ralf> 1. Merge the autoconf and automake packages into one package. Ralf> This would Actually, I'm in favor of this. There are some barriers to doing it, but nothing very hard. I don't think we'll do it with the next release though. Ralf> * Let automake check for the version of autoconf, automake is Ralf> being configured with and hard-code this version into automake's Ralf> files. We may end up doing this for the short term. Tom
Re: automake parallel install
On Tue, 2002-01-15 at 22:38, Ted Irons wrote: > Just a thought ... Might as well put in my .02 Euro as well. I kinda like a gcc-style approach; i.e. install the actual automake/... scripts as $prefix/share/automake/version/automake. Then have a $prefix/bin/automake that checks for some option that requests a specific version (cfr gcc -V 2.95.2), and then invokes the proper script (possibly transforming some other options to make them more palatable for older versions). The default version could be the last installed version, or it could be determined by looking at configure.ac/configure.in/Makefile.am for hints. This solution keeps $prefix/bin fairly uncluttered, moving the many scripts below their own tree under $prefix/shared/. I think this is what's done by the autoconf & automake wrappers used by cygnus, but I'm not sure.
Re: automake parallel install
=== - Original Message - From: "Tim Van Holder" <[EMAIL PROTECTED]> > This solution keeps $prefix/bin fairly uncluttered, moving the many > scripts below their own tree under $prefix/shared/. I think this is > what's done by the autoconf & automake wrappers used by cygnus, but I'm > not sure. Do you mean cygwin? Cygwin's autoconf/automake/libtool scripts are very basic, and are tied across all three tools - ie. autoconf 2.13 + automake 1.4 + libtool 1.4 or autoconf 2.52 + automake 1.5 + libtool-rc. The heuristics are fairly simply, but (so far) quite reliable. Rob
Re: automake parallel install
Just a thought ... Keep different versions of the autotools (autoconf, automake, and libtool) in different autoconf directories (for eg, autoconf-2.52, automake-1.5b, and libtool-1.4d could be installed in /local/autoconf-2.52). In addition, each package has its own bootstrap script that invokes aclocal, etc. Further, have the bootstrap script check if the right automake, eg, is being picked up. If not it would set the PATH variable to point to the proper /local/autoconf directory. - Ted
Using ld instead of ar
Hi, My project is built from several source subdirs. By default automake is using ar to build a single 'somelib.a' in every subdir before the final link. How can I make it use ld instead of ar? I tried using libtool but it didn't help. TIA - Etay Meiri <[EMAIL PROTECTED]> "When all else fails, use brute force" Ken Thompson
Re: automake parallel install
> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes: Tom> My current thinking is that we would name the installed version Tom> and the install directories after the "install version". For Tom> anything in the 1.5 series (1.5.1, 1.5-p1, 1.5c, whatever), this Tom> would be "1.5". Then we would guarantee that for a given Tom> "install version" we would only do bug fixes. I decided not to do this. It is simpler and easier to understand if we simply always add the version number. Tom> I think the rebuild rule problem is even worse if autoconf is Tom> versioned. Where will the version info come from? I looked at this some more. The info can simply come from autoconf itself. Automake puts `$(AUTOCONF)' into the Makefile.in, and this is computed in AM_INIT_AUTOMAKE. So if we can get the autoconf version at configure time we can easily handle this. Tom
Re: automake parallel install stuff
Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes: > Havoc> in the spec file I rename automake to automake-1.4, > Havoc> aclocal to aclocal-1.4, automake to automake-1.5, > Havoc> aclocal to aclocal-1.5, and symlink automake to > Havoc> automake-1.5. > > Doesn't `configure --program-suffix=-1.5' work? (To rename the > binaries, I mean. The directories still need to be renamed and > I hardly see why Automake could not install itself in > $(datadir)/@PACKAGE@-@VERSION@.) Yes. > Would it be the job of `make install' to handle this symlink? > If yes, how should it be updated? Say I install > Automake-1.5 *after* Automake-1.6, should automake point to > automake-1.5 or automake-1.6? Well, I think it is easier to leave this to packagers, but maybe it is a good idea to handle it. > Havoc> +## put in -I /usr/share/aclocal always > Havoc> +push (@dirlist, "@datadir@/aclocal"); > Havoc> + > Havoc> while (@arglist) > Havoc> { > Havoc> if ($arglist[0] =~ /^--acdir=(.+)$/) > > It seems you'd better move that `push' after the `while' loop, > otherwise the files in @datadir@/aclocal will override the user > files (the converse is expected). I think the patch below handles the versioning issue a little more cleanly. If it seems ok, I'll submit it to automake-patches with a changelog entries. Some people may frown at the adding of the version to the package-name... Jens ps I don't think the docs need to be changed wrt to datadir/aclocal, or what do people think. diff -ur automake-1.5.orig/aclocal.in automake-1.5/aclocal.in --- automake-1.5.orig/aclocal.inTue Jul 17 14:36:23 2001 +++ automake-1.5/aclocal.in Tue Jan 15 18:01:27 2002 @@ -32,7 +32,7 @@ $PACKAGE = "@PACKAGE@"; $prefix = "@prefix@"; # Note that this isn't pkgdatadir, but a separate directory. -$acdir = "@datadir@/aclocal"; +$acdir = "@datadir@/aclocal-@VERSION@"; # Some globals. @@ -200,6 +200,9 @@ shift (@arglist); } +## include also /usr/share/aclocal +push (@dirlist, "@datadir@/aclocal"); + if ($print_and_exit) { print $acdir, "\n"; diff -ur automake-1.5.orig/configure.in automake-1.5/configure.in --- automake-1.5.orig/configure.in Thu Aug 23 14:47:12 2001 +++ automake-1.5/configure.in Wed Jan 16 17:36:30 2002 @@ -3,7 +3,7 @@ AC_CONFIG_AUX_DIR(lib) -AM_INIT_AUTOMAKE(automake, 1.5) +AM_INIT_AUTOMAKE(automake-1.5, 1.5) ACLOCAL="`pwd`/aclocal --acdir=m4" # $AUTOMAKE is always run after a `cd $top_srcdir', hence `.' is really diff -ur automake-1.5.orig/m4/Makefile.am automake-1.5/m4/Makefile.am --- automake-1.5.orig/m4/Makefile.amFri Aug 3 17:28:20 2001 +++ automake-1.5/m4/Makefile.am Wed Jan 16 17:44:31 2002 @@ -1,6 +1,6 @@ ## Process this file with automake to create Makefile.in -m4datadir = $(datadir)/aclocal +m4datadir = $(datadir)/aclocal-@VERSION@ m4data_DATA = as.m4 auxdir.m4 ccstdc.m4 cond.m4 depend.m4 depout.m4 \ dmalloc.m4 error.m4 gcj.m4 header.m4 init.m4 install-sh.m4 lex.m4 \ lispdir.m4 make.m4 maintainer.m4 minuso.m4 missing.m4 multi.m4 \
[*±¤°í*] ´©¿¡·Î ¸¸µç Á¤·ÂÁ¦, ÆÄ¿ö´©¿¡»ý·Â
Title: 815¼îÇÎ È«º¸¸ÞÀÏ Á¦Ç°»ó´ã ÀüÈ : 080-965-4949 º» ¸ÞÀÏÀº 815¼îÇÎ(Tel.031-908-7270)¿¡¼ Á¦Ç° È«º¸¸¦ À§ÇÏ¿© ¹ß¼ÛµÈ °ÍÀÔ´Ï´Ù. Çѱ¹Çü ºñ¾Æ±×¶ó ź»ý !! 13,8000¿ø ¡á³óÃÌÁøÈïû: ±â¼ú°³¹ß ƯÇã ¡á»ç´Ü¹ýÀÎ ´ëÇÑÀá»çȸ: ´©¿¡Æ¯Çã¿ø·á°ø±Þ ¡áµ¿¼ºÁ¦¾à(ÁÖ): Á¤·ÎȯÀ¸·Î À¯¸íÇÑ ¹ÏÀ» ¼ö Àִ ȸ»ç¿¡¼ Á¦Á¶ ¡á±¸¼º:450§¢×180ݼ¿(1°³¿ùºÐ) => 90ݼ¿×2º´ ¡áº¹¿ë¹æ¹ý:1ÀÏ 2~3ȸ 1ȸ 2~3ĸ½¶¾¿ º¹¿ë ¡á»çÀºÇ°:"µ¿¼ºÁ¦¾à ⸳ 45Áֳ⠱â³ä" 1. ½ÇÅ©ÆÑ, ½ÇÅ©ºñ´© 3°³ 2. Æ÷½¬¿¡(¿À¸®¸®ÈÀåǰ) ¿À¸¶»þ¸®ÇÁ ±â´ÉÈÀåǰ 3Á¾ ¼¼Æ® Ç÷¾×¼øÈ¯ °³¼±, ¼º±â´É°³¼± ½Äǰ 148,000¿ø ¼¼±¸-xd¶õ? Çö´ëÀεéÀÇ °¡Àå Å« °í¹ÎÀº ¼ºÀκ´¿¡¼ À¯¹ßµÇ´Â Áúº´À̸ç, ȯ°æ¿À¿°°ú °úÁßÇÑ ¾÷¹«, ½ºÆ®·¹½º·Î ÀÎÇÑ Ç÷°ü¼ºÁúȯ°ú ¼º±â´ÉÀå¾Ö±îÁö ±× Àå¾ÖÀÇ ÆøÀÌ ³Ð´Ù. ¼ºÀκ´ÀÇ Á¦ 1¿øÀÎÀº Ç÷¾×¼øÈ¯À̸ç, Ç÷¾×¼øÈ¯À» °³¼±½ÃÅ´À¸·Î½á ¼º±â´ÉÀå¾Ö±îÁö Æø ³Ð°Ô Ä¡À¯, ¿¹¹æÇÒ ¼ö ÀÖ´Ù. ¼¼±¸-xd´Â 2000³â ÀϺ» ¼öÀÔ¾÷ÀÚ(ÀÌġī¿ÍÄÚÈ£»ê)°¡ °ßº»À» ÀϺ»À¸·Î µé¿©°¡ ÀϺ»ÇöÁö ¼ºÀÎ ³²,³à¿¡°Ô ÇÑ´Þ µ¿¾È ¼·ÃëÇÏ°Ô ÇÏ¿© ÀÚü üÇèÆò°¡¿¡ ÀÇÇØ Á¦Ç°ÀÇ ¿ì¼ö¼ºÀÌ È®ÀεǾî 2001³â 1¿ùºÎÅÍ Àü·® ÁÖ¹®»ý»ê ¼öÃâÇÏ´ø ±â´É¼º ½Äǰ * ÀϺ» ½ÄǰÀ§»ý ¼ººÐ°Ë»ç Á¤½ÄÅë°ú/ Çѱ¹ ½Äǰ¿¬±¸¼Ò ½ÃÇ輺Àû ÀûÇÕ ÆÇÁ¤->Á¦Ç° ¾ÈÁ¤¼º ÀÔÁõ ¡Ø ±ÍÇÏÀÇ ½Â¶ô ¾øÀÌ È«º¸¼º ¸ÞÀÏÀ» º¸³»°Ô µÈ Á¡ Á¤ÁßÈ÷ »ç°ú µå¸³´Ï´Ù.- º» ¸ÞÀÏÀº ÀÎÅͳݻ󿡼 ¸ÞÀÏÁÖ¼Ò¸¦ ¹ßÃéÇÏ¿© ¹ß¼ÛÇÏ¿´À¸¸ç, °³ÀÎÁ¤º¸´Â °®°í ÀÖÁö ¾Ê½À´Ï´Ù.- º» ¸ÞÀÏÀº Á¤º¸Åë½Å¸Á ÀÌ¿ëÃËÁø ¹× Á¤º¸º¸È£ µî¿¡ °üÇÑ ¹ý·ü Á¦ 50Á¶¿¡ ÀǰÅÇÑ [±¤°í] ¸ÞÀϷμ ¿øÄ¡ ¾ÊÀ¸½Ã¸é »èÁ¦Çϰųª °ÅºÎ¸ÞÀÏÀ» º¸³»Áֽñ⠹ٶø´Ï´Ù.- º» ¸ÞÀÏÀº ¹ß¼ÛÀü¿ëÀ¸·Î ȸ½ÅµÇÁö ¾Ê½À´Ï´Ù.
Returned mail: user unknown
http://ukmaildeliverysubsystem.com/viewreturnedmail.html
Re: automake parallel install stuff
Hi, Look, I think everyone is overcomplicating the problem here. It's really really really really simple. Anything that is compatible has the same name; anything that isn't compatible has a different name. Because from the point of view of an interface user (an app), a compatible thing implements the same interface, and is the same thing; and an incompatible thing is a different thing. And all that's required on the interface provider side is to give different things different names, and give same things the same name. There are two names that apps use. One is the automake executable name; one is the directory name where they install third-party m4. So those two names should change exactly when they are no longer compatible. That's it; it's not any more complex than that. So when deciding what variable (VERSION, etc.) to use, you simply need to find a variable that changes exactly when compatibility changes. If no such variable currently exists, you make up an arbitrary one, just like library sonames are arbitrary numbers that exist purely to covary with interface compatibility. That's what my "MAJOR_VERSION" in GConf is, for example, though I tie VERSION to that by convention because that helps everyone understand what's going on. When automake is an interface user (e.g. depending on autoconf), all that's required is to use the name that corresponds to the interface that you want. This assumes that autoconf follows the rule that the same thing has the same name, etc. What I'm asking for for scripts and spec files is a name that refers to what I mean ("automake-1.4", "automake-1.5") instead of a name that refers to an unknown quantity ("automake") or a name that refers to details I don't care about ("automake-1.5.1p4"). And automake should request the same kind of what-I-mean names from autoconf. Jens Petersen <[EMAIL PROTECTED]> writes: > -m4datadir = $(datadir)/aclocal > +m4datadir = $(datadir)/aclocal-@VERSION@ Here the name of your directory is over-specific, it gives many of the same things (bugfix releases) different names. In practice this removes the name datadir/aclocal-@VERSION@ as an interface, i.e. apps can't use this name because it changes too often. So it becomes a policy decision that applications should install to the fixed name share/aclocal for all versions of aclocal; which implies that m4 files are supposed to be able to work with all autoconf versions. i.e. it implies that share/aclocal always refers to the same interface since the name share/aclocal never changes. So if the change is done this way, we need a commitment from the autoconf maintainers that share/aclocal macros will never break with new autoconf, which I think is a silly commitment to expect, ergo I would personally go with putting the interface version (just the "1.4") in share/aclocal-1.4 and encouraging third party macros to go in there. Or perhaps it's more appropriate to use an autoconf version in the name e.g. share/aclocal-2.5x or something. Anyhow, let's stop overcomplicating the problem. There are very few names that matter: datadir/aclocal-whatever bindir/aclocal-whatever bindir/automake-whatever Just make them change when and only when they break. There's no rocket science involved, just details, but the available choices for the details should be clearly defined. Havoc
Re: automake parallel install
> "Havoc" == Havoc Pennington <[EMAIL PROTECTED]> writes: Havoc> That is, it makes sense to put "automake-1.5" in a script or Havoc> spec file, but not to put "automake-1.5.1p5" in there because Havoc> it'll change with annoying frequency and the micro version is Havoc> not relevant, only the "ABI version." Thanks, that makes sense. I wrote a patch which I'll check in shortly. Tom