Automake 1.5

Automake 1.5

[Ronald Landheer]

Hello all,

Frankly, I don't know whether this is Cygwin-specific. If not, please 
redirect this post (and me) to the proper list (of which I do not have 
the E-mail address, so redirecting me would be giving me the proper 
address). Thanx

Recently, I have re-installed and updated Cygwin (the update part is 
done every Sunday) and have installed Automake 1.5 in the process.

Today, I found that automake apparently depends on Libtool when building 
my Eleanor project - libtool is a tool I do know but do not use by 
choice. Eleanor consists of a software development kit for a PBEM game 
(VGA Planets) and a general tool/replacement library (Swing), and as 
such has four libraries in it. It would seem obvious to use Libtool for 
this, but as I said, I don't want to.

Thus, Automake 1.5 broke my bootstrap script and does not allow me to compile Eleanor without problems any more. My questions are:
  a. Is this normal behaviour for Automake 1.5?
     i.e. is it normal for Automake to want to use Libtool, even if I 
     don't?
  b. How do I get rid of this, w/o downgrading to the previous version 
     of Automake (which I just did, to be able to build Eleanor and 
     thus, one of the programs that depends on this project)

Like I said, if this is not Cygwin-specific, please redirect me and this 
message to the proper place.

Have a very, very nice day!

Ronald

NB: I also find this new dependency tracking system very, very 
    annoying..


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Automake 1.5

[Charles Wilson]

Ronald Landheer wrote:


> Frankly, I don't know whether this is Cygwin-specific. If not, please 
> redirect this post (and me) to the proper list (of which I do not have 
> the E-mail address, so redirecting me would be giving me the proper 
> address). Thanx


Well, many folks have been happily using Automake-1.5 on cygwin without 
libtool; it must be something about your .am files that is pulling in 
that dependency.  I think this is an automake question primarily, and 
only secondarily a cygwin question.  You'd probably be better off on the 
automake list (automake@gnu.org).

> 
> NB: I also find this new dependency tracking system very, very 
>     annoying..

First, the new dependency stuff in setup is new, and will doubtless need 
refining.  Second, you're going to HAVE to be a little more specific. 
Also, your annoyance has to be balanced against (1) all those newbies 
who only install parts of cygwin (and get the wrong parts and neglect to 
install actual dependencies: gcc without binutils, etc), and (2) 
everybody else who is annoyed that OUR first response to people in (1) 
is "download and install the entire 300M distribution.

We HAVE to have dependency tracking, but nobody claims that setup's 
implementation is perfect.  Help us.

--Chuck


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Automake 1.5

[Christopher Faylor]

On Sat, Sep 08, 2001 at 11:57:39AM -0400, Charles Wilson wrote:
>Ronald Landheer wrote:
>
>
>>Frankly, I don't know whether this is Cygwin-specific. If not, please 
>>redirect this post (and me) to the proper list (of which I do not have 
>>the E-mail address, so redirecting me would be giving me the proper 
>>address). Thanx
>
>
>Well, many folks have been happily using Automake-1.5 on cygwin without 
>libtool; it must be something about your .am files that is pulling in 
>that dependency.  I think this is an automake question primarily, and 
>only secondarily a cygwin question.  You'd probably be better off on the 
>automake list (automake@gnu.org).
>
>>
>>NB: I also find this new dependency tracking system very, very 
>>    annoying..
>
>First, the new dependency stuff in setup is new, and will doubtless need 
>refining.  Second, you're going to HAVE to be a little more specific. 
>Also, your annoyance has to be balanced against (1) all those newbies 
>who only install parts of cygwin (and get the wrong parts and neglect to 
>install actual dependencies: gcc without binutils, etc), and (2) 
>everybody else who is annoyed that OUR first response to people in (1) 
>is "download and install the entire 300M distribution.
>
>We HAVE to have dependency tracking, but nobody claims that setup's 
>implementation is perfect.  Help us.

AFAIK, the dependency tracking stuff in setup hasn't been released.  Was
Ronald referring to dependency tracking in automake, perchance?

If so, this is clearly the wrong forum for this type of complaint.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: Automake 1.5

[Ronald Landheer]

Hello Christopher,
> AFAIK, the dependency tracking stuff in setup hasn't been released. 
> Was Ronald referring to dependency tracking in automake, perchance?
> If so, this is clearly the wrong forum for this type of complaint.
In deed I was, and in deed it isn't :)
I was just airing my frustration a bit (about the dependecy tracking).

Greetz!

Ronald


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: Automake 1.5

[Ronald Landheer]

Hello Charles..

> Well, many folks have been happily using Automake-1.5 on cygwin
> without libtool; it must be something about your .am files that is
> pulling in that dependency.  I think this is an automake question
> primarily, and only secondarily a cygwin question.  You'd probably be
> better off on the automake list (automake@gnu.org).
OK, I'll redirect my question there. Thing is, though, that neither my Makefile.am nor my configure.in file contains _any_ reference to Libtool. I've installed Libtool 1.4 (which runs OOTB) on my Cygwin, and there is no more problem. It doesn't create Libtool libraries (which is why I don't want to use libtool) but I'm not sure what it is doing.
Like I said, I'll redirect my question to automake@gnu.org.

Thanx!

>> NB: I also find this new dependency tracking system very, very 
>>     annoying..
> First, the new dependency stuff in setup is new, and will doubtless
> need refining.  Second, you're going to HAVE to be a little more
> specific. Also, your annoyance has to be balanced against (1) all
> those newbies who only install parts of cygwin (and get the wrong
> parts and neglect to install actual dependencies: gcc without
> binutils, etc), and (2) everybody else who is annoyed that OUR first
> response to people in (1) is "download and install the entire 300M
> distribution.
> We HAVE to have dependency tracking, but nobody claims that setup's
> implementation is perfect.  Help us.
Sorry - I wasn't talking about setup - that's just fine (if I have 
anything to say about that, I will certainly be more specific & try to 
find a solution :) I was talking about Automake's dependency tracking, 
which doesn't seem to work for me - though I see no reason why it 
wouldn't..
Another question for the appropriate list :) (But for the moment, I've 
just shut it off)

Thanx & Greetz!

Ronald


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Automake 1.5

[James Youngman]

"Ronald Landheer" <info@rlsystems.net> writes:

> Recently, I have re-installed and updated Cygwin (the update part is 
> done every Sunday) and have installed Automake 1.5 in the process.

[...]

> Thus, Automake 1.5 broke my bootstrap script and does not allow me
> to compile Eleanor without problems any more. My questions are:

I have also had to downgrade this stuff, becuase the latest version of
autoconf insists on using config.sub even if all you want to do is
figure out the value of EXEHDR.  Previous versions of autoconf didn't
require that. The problem is that the current version of automake
doesn't know to include config.sub even though autoconf needs it :-(

-- 
James Youngman
Manchester, UK.  +44 161 226 7339
PGP (GPG) key ID for <jay@gnu.org> is 64A95EE5 (F1B83152).

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Automake 1.5

[Christopher Faylor]

On Sun, Sep 09, 2001 at 01:35:56PM +0100, James Youngman wrote:
>"Ronald Landheer" <info@rlsystems.net> writes:
>>Recently, I have re-installed and updated Cygwin (the update part is
>>done every Sunday) and have installed Automake 1.5 in the process.
>
>[...]
>
>>Thus, Automake 1.5 broke my bootstrap script and does not allow me to
>>compile Eleanor without problems any more.  My questions are:
>
>I have also had to downgrade this stuff, becuase the latest version of
>autoconf insists on using config.sub even if all you want to do is
>figure out the value of EXEHDR.  Previous versions of autoconf didn't
>require that.  The problem is that the current version of automake
>doesn't know to include config.sub even though autoconf needs it :-(

FWIW, Chuck Wilson has also identified some incompatibilities between
the newest version of autoconf and libiberty's configure.in.

I wonder if we should drop back to an older version for a while in the
cygwin distro.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Automake 1.5

[Charles Wilson]

Christopher Faylor wrote:


> FWIW, Chuck Wilson has also identified some incompatibilities between
> the newest version of autoconf and libiberty's configure.in.
> 
> I wonder if we should drop back to an older version for a while in the
> cygwin distro.


AAAGGGHHH!!!! Not you, too, Chris!

The new autoconf and automake are necessary if we ever want to get 
libtool to build dll's transparently.  That's the tradeoff.

Permanent stasis with 2.13/1.4, or forward progression and some new 
features (and bugfixes.  Did I mention bugfixes?) in the 2.52/1.5 
versions.  But it means folks have to make the adjustment in a lot of 
different packages -- including libiberty, gcc, etc.

Again, *what* is the resistance?  *Why* don't folks want to upgrade -- 
even when handed a patch?

--Chuck



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Automake 1.5

[Christopher Faylor]

On Sun, Sep 09, 2001 at 07:54:27PM -0400, Charles Wilson wrote:
>Christopher Faylor wrote:
>
>
>>FWIW, Chuck Wilson has also identified some incompatibilities between
>>the newest version of autoconf and libiberty's configure.in.
>>
>>I wonder if we should drop back to an older version for a while in the
>>cygwin distro.
>
>
>AAAGGGHHH!!!! Not you, too, Chris!
>
>The new autoconf and automake are necessary if we ever want to get 
>libtool to build dll's transparently.  That's the tradeoff.
>
>Permanent stasis with 2.13/1.4, or forward progression and some new 
>features (and bugfixes.  Did I mention bugfixes?) in the 2.52/1.5 
>versions.  But it means folks have to make the adjustment in a lot of 
>different packages -- including libiberty, gcc, etc.
>
>Again, *what* is the resistance?  *Why* don't folks want to upgrade -- 
>even when handed a patch?

If we can have a patched version of 2.52 that works fine with older
configure.in's then that's fine.

I'm concerned about the necessity of requiring one
configure.in/Makefile.am for working with "cygwin" and one for working
with the rest of the world.

I *would* like to have a libtool that works properly on Windows but we
have no control over all of the myriad other packages that apparently
need to be changed.

I just checked and even Red Hat's Rawhide distribution has not yet upgraded
to a newer autoconf.

I like using the newest versions of things, especially when they fix problems
on windows.  I don't like causing people unnecessary grief for Cygwin when
they don't have to (yet) suffer the grief on other platforms.

If I am understanding what's going on here correctly, it sounds like packages
that used to work on cygwin with older versions of autoconf now need to be
changed to accomodate our newer tools.  That would be ok if the rest of the
world was starting to upgrade but...  that's not happening yet, AFAICT.

I don't like this, but this is one of those situations where you have to choose
between the frying pan and the fire.  Neither choice is perfect.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Automake 1.5

[Robert Collins]

On Mon, 2001-09-10 at 10:06, Christopher Faylor wrote:

> I don't like this, but this is one of those situations where you have to choose
> between the frying pan and the fire.  Neither choice is perfect.

borrow from debian? they have an autoconf wrapper that runs a heuristic
and then runs either autoconf 2.13 or 2.52.

Rob


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Automake 1.5

[Christopher Faylor]

On Mon, Sep 10, 2001 at 10:08:56AM +1000, Robert Collins wrote:
>On Mon, 2001-09-10 at 10:06, Christopher Faylor wrote:
>>I don't like this, but this is one of those situations where you have
>>to choose between the frying pan and the fire.  Neither choice is
>>perfect.
>
>borrow from debian?  they have an autoconf wrapper that runs a
>heuristic and then runs either autoconf 2.13 or 2.52.

Sure.  Sounds like a workable solution.

Debian is a great..., um, er, no comment.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Automake 1.5

[Charles Wilson]

James Youngman wrote:


>>Thus, Automake 1.5 broke my bootstrap script and does not allow me
>>to compile Eleanor without problems any more. My questions are:
>>
> 
> I have also had to downgrade this stuff, becuase the latest version of
> autoconf insists on using config.sub even if all you want to do is
> figure out the value of EXEHDR.  Previous versions of autoconf didn't
> require that. The problem is that the current version of automake
> doesn't know to include config.sub even though autoconf needs it :-(


Okay, I'd like for somebody to explain this to me.  (Really, I'm 
asking).  I've seen this in gcc, libiberty, and several other projects 
that depend on autotools.

The autoconf people have deprecated 2.13.  New development will be based 
on autocon-2.52 and later. 2.13 is dead. It is no more.  It has ceased 
to be.  It's expired and gone to meet its maker.  Bereft of life, it 
rests in peace.  Shuffled off this mortal coil.  Joined the choir 
invisible.  Bleedin' deceased.  (sorry, got carried away; but wasn't 
Monty Python's "The Pet Shop" a *great* sketch?)

The automake people have updated. Their recommended, official version is 
1.5, not 1.4.1 or 1.4 or 1.4p2 or whatever.

Now, in both cases there are a few backwards-incompatibilities.  Thus, 
projects that use the autotools will require some changes in order to 
work with the new versions.  So why is the first response always to 
downgrade back to the old, obsolete versions of the autotools -- instead 
of patching the project to use the new autotools (or better, patching 
the project with compatibility macros to support both 2.13 and 
2.52(autoconf))

I even submitted patches for libiberty to support both versions, but it 
was more or less ignored.  It seems the response was "we're sticking 
with 2.13"

What?  Forever?

I don't understand.  Help me?

--Chuck



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Automake 1.5

[Christopher Faylor]

On Sun, Sep 09, 2001 at 07:47:12PM -0400, Charles Wilson wrote:
>I even submitted patches for libiberty to support both versions, but it 
>was more or less ignored.  It seems the response was "we're sticking 
>with 2.13"
>
>What?  Forever?
>
>I don't understand.  Help me?

I don't understand the sticking with 2.13 response either.  It seems
like there is a disconnect between the autotools maintainers and the
maintainers of the packages that they're trying to help.

However, it seems to me to be most politic for cygwin to follow the
herd rather than to lead it in cases like this.  If no one is moving
to 2.5*, for whatever reason, then maybe we shouldn't be using the
latest and greatest either.

When 90% of the world has switched to the newer tools, then we can
switch.  At that point we'll have a stronger case for switching,
I think.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: Automake 1.5

[Ronald Landheer]

Hello Chuck,

> (sorry, got carried away; but wasn't Monty Python's "The Pet Shop" a
> *great* sketch?)
It certainly was :)
> So why is the first response always to downgrade back to the old,
> obsolete versions of the autotools -- instead of patching the project
> to use the new autotools (or better, patching the project with
> compatibility macros to support both 2.13 and 2.52(autoconf))
Because when you find out there is a problem, you want to bootstrap and 
build your project - so you get that done first. *Then*, after 
bootstrapping and building, you put your new versions back and see what 
the problem is. You fix, and lo and behold, bootstrapping and building 
works again.

What I sent the original mail for, was that Automake was asking for 
something it should not need. I've redirected to the proper list.

> I even submitted patches for libiberty to support both versions, but
> it was more or less ignored.  It seems the response was "we're
> sticking with 2.13"
> What?  Forever?
> I don't understand.  Help me?
That, I don't understand either..
Strange..

Greetz!

Ronald

NB: meant to ask: what is your thesis about? Just curious..


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Automake 1.5

[James Youngman]

Charles Wilson <cwilson@ece.gatech.edu> writes:

> James Youngman wrote:
> 
> 
> >>Thus, Automake 1.5 broke my bootstrap script and does not allow me
> >>to compile Eleanor without problems any more. My questions are:
> >>
> > I have also had to downgrade this stuff, becuase the latest version
> > of
> > autoconf insists on using config.sub even if all you want to do is
> > figure out the value of EXEHDR.  Previous versions of autoconf didn't
> > require that. The problem is that the current version of automake
> > doesn't know to include config.sub even though autoconf needs it :-(
> 
> 
> Okay, I'd like for somebody to explain this to me.  

[...]

> Now, in both cases there are a few backwards-incompatibilities.  Thus,
> projects that use the autotools will require some changes in order to
> work with the new versions.  So why is the first response always to
> downgrade back to the old, obsolete versions of the autotools --
> instead of patching the project to use the new autotools (or better,
> patching the project with compatibility macros to support both 2.13
> and 2.52(autoconf))
> 
> I even submitted patches for libiberty to support both versions, but
> it was more or less ignored.  It seems the response was "we're
> sticking with 2.13"
> 
> What?  Forever?
> 
> I don't understand.  Help me?

The problem (for me) is not that I refuse to upgrade to either; it's
that the two versions are _incompatible_; automake is supposed to
supply those dependencies that it produces (e.g. install-sh, missing,
etc.) and that autoconf produces (e.g. config.sub).  It's that with
these two particular versions, a particular autoconf macro now
requires a file which automake usually does provide, but automake
doesn't know about the dependency.  

This means that for me, there is a temporary workaround of not
upgrading to the latest version of autoconf until automake catches up
with the new situation. 

So, I'm not _permanently_ refusing to upgrade; I'm just deferring an
upgrade to autoconf until I can upgrade automake to a version that's
compatible.   

-- 
James Youngman
Manchester, UK.  +44 161 226 7339
PGP (GPG) key ID for <jay@gnu.org> is 64A95EE5 (F1B83152).

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/