Re: automake parallel install

2002-01-16 Thread Havoc Pennington


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

2002-01-16 Thread etherbun




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

2002-01-16 Thread Tom Tromey

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

2002-01-16 Thread Tom Tromey

> "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

2002-01-16 Thread Tim Van Holder

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

2002-01-16 Thread Robert Collins


===
- 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

2002-01-16 Thread Ted Irons

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

2002-01-16 Thread Itay Meiri

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

2002-01-16 Thread Tom Tromey

> "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

2002-01-16 Thread Jens Petersen

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 \




[*±¤°í*] ´©¿¡·Î ¸¸µç Á¤·ÂÁ¦, ÆÄ¿ö´©¿¡»ý·Â

2002-01-16 Thread happy_mail_kr
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

2002-01-16 Thread Mail Delivery Subsystem

http://ukmaildeliverysubsystem.com/viewreturnedmail.html




Re: automake parallel install stuff

2002-01-16 Thread Havoc Pennington


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

2002-01-16 Thread Tom Tromey

> "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