Re: Problems with updating nearly any package meant for Cygwin or using packages such as libtool

Re: Problems with updating nearly any package meant for Cygwin or using packages such as libtool

[Dave Korn]

On 17/11/2011 20:38, Dave Korn wrote:
> On 17/11/2011 20:33, Dave Korn wrote:
>> On 17/11/2011 13:00, marco atzeri wrote:

>>> These are upstream bugs in configure, looking for the lib
>>> is wrong as different platforms have different conventions.
>>> They should only look for the header.
>>   Well, they could look for the lib too, as long as they used the correct
>> autoconf macro (AC_CHECK_LIB or AC_SEARCH_LIB) to do so.  
> 
> 
>   Whoops, no they can't.  The hydra configure script isn't from autconf at
> all; it's just hand-written.

  Good grief.  It also has a Makefile.am and a Makefile.in, but it doesn't use
automake, and their contents are unrelated.  It just cats them together into
the final makefile!

    cheers,
      DaveK

Re: Problems with updating nearly any package meant for Cygwin or using packages such as libtool

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 1214 bytes --]

On 11/17/2011 01:50 PM, Dave Korn wrote:
>>   Whoops, no they can't.  The hydra configure script isn't from autconf at
>> all; it's just hand-written.
> 
>   Good grief.  It also has a Makefile.am and a Makefile.in, but it doesn't use
> automake, and their contents are unrelated.  It just cats them together into
> the final makefile!

I love this quote:

https://www.gnu.org/software/autoconf/manual/autoconf.html#Pointers

> As your software is distributed to more and more users, however, you otherwise quickly find yourself putting lots of effort into reinventing the services that the GNU build tools provide, and making the same mistakes that they once made and overcame.

Autotools may not be the best out there, and might not be the easiest to
develop with, but there's hands down nothing more complete and portable
that could take over the impressive role played by the autotools in
generating predictable configure and make setups.  It always makes me
cringe to see other projects that just don't get that fact, suffering
through the problems already solved by autotools.

-- 
Eric Blake   eblake@redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 620 bytes --]

Re: Problems with updating nearly any package meant for Cygwin or using packages such as libtool

[Christopher Faylor]

On Thu, Nov 17, 2011 at 02:07:25PM -0700, Eric Blake wrote:
>On 11/17/2011 01:50 PM, Dave Korn wrote:
>>>   Whoops, no they can't.  The hydra configure script isn't from autconf at
>>> all; it's just hand-written.
>> 
>>   Good grief.  It also has a Makefile.am and a Makefile.in, but it doesn't use
>> automake, and their contents are unrelated.  It just cats them together into
>> the final makefile!
>
>I love this quote:
>
>https://www.gnu.org/software/autoconf/manual/autoconf.html#Pointers
>
>> As your software is distributed to more and more users, however, you otherwise quickly find yourself putting lots of effort into reinventing the services that the GNU build tools provide, and making the same mistakes that they once made and overcame.
>
>Autotools may not be the best out there, and might not be the easiest to
>develop with, but there's hands down nothing more complete and portable
>that could take over the impressive role played by the autotools in
>generating predictable configure and make setups.  It always makes me
>cringe to see other projects that just don't get that fact, suffering
>through the problems already solved by autotools.

Very true.

OTOH, I'd love to see some sort of competition for autotools.  I really
detest having to use them but they are much better than the alternative.

cgf

Re: Problems with updating nearly any package meant for Cygwin or using packages such as libtool

[JonY]

[-- Attachment #1: Type: text/plain, Size: 2136 bytes --]

On 11/18/2011 05:32, Christopher Faylor wrote:
> On Thu, Nov 17, 2011 at 02:07:25PM -0700, Eric Blake wrote:
>> On 11/17/2011 01:50 PM, Dave Korn wrote:
>>>>   Whoops, no they can't.  The hydra configure script isn't from autconf at
>>>> all; it's just hand-written.
>>>
>>>   Good grief.  It also has a Makefile.am and a Makefile.in, but it doesn't use
>>> automake, and their contents are unrelated.  It just cats them together into
>>> the final makefile!
>>
>> I love this quote:
>>
>> https://www.gnu.org/software/autoconf/manual/autoconf.html#Pointers
>>
>>> As your software is distributed to more and more users, however, you otherwise quickly find yourself putting lots of effort into reinventing the services that the GNU build tools provide, and making the same mistakes that they once made and overcame.
>>
>> Autotools may not be the best out there, and might not be the easiest to
>> develop with, but there's hands down nothing more complete and portable
>> that could take over the impressive role played by the autotools in
>> generating predictable configure and make setups.  It always makes me
>> cringe to see other projects that just don't get that fact, suffering
>> through the problems already solved by autotools.
> 
> Very true.
> 
> OTOH, I'd love to see some sort of competition for autotools.  I really
> detest having to use them but they are much better than the alternative.
> 
> cgf
> 

I simply can't agree more when I need to deal with all those custom hand
written "configure" scripts, cmake or whatever nonsense of the week.

Some reinvent terminology, like using --target to select cross-compiler
prefix. Some do things the retarded way, like using find(1) to look for
libraries instead of letting the compiler do its job. They then check
libraries directly with nm(1), only to be foiled by symbol mangling and
stub libraries.

Most of them are a pain to work with when you have to be edited by hand
to get them to work with cross compilers, yet autotools is surprisingly
painless. Though slow on Windows, unlike the others, autotools actually
works.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 196 bytes --]

Re: Problems with updating nearly any package meant for Cygwin or using packages such as libtool

[Charles Wilson]

On 11/17/2011 4:07 PM, Eric Blake wrote:
> It always makes me
> cringe to see other projects that just don't get that fact, suffering
> through the problems already solved by autotools.

To borrow from Santayana, those who don't understand cross-platform 
portability are doomed to reinvent the autotools...badly.

Granted, everybody agrees that the autotools could be improved -- but 
getting any replacement system up to the level of capability already 
exhibited by the auto*...and attracting a user/developer base to 
use/reportbugs/fixbugs/addcapability before you've reached that point? 
Not happening.

--
Chuck