Re: Mac OS X Snow Leopard and 64-bit applications
Re: Mac OS X Snow Leopard and 64-bit applications
- Subject: Re: Mac OS X Snow Leopard and 64-bit applications
- From: Andrew Gallatin <email@hidden>
- Date: Mon, 31 Aug 2009 15:27:29 -0400
Mo McRoberts wrote:
On Mon, Aug 31, 2009 at 19:19, Andrew Gallatin<email@hidden> wrote:
If you never intend to support odd platforms, it may not
be too evil. But once you go beyond linux or BSD and have
no longer have a GNUish envoronment, then it gets ugly fast.
I once spent about 2 days trying to get libtool to work on Aix.
MacOSX was pretty miserable with libtool back in the early
days (2002 or so). It may have improved.
It is far easier to simply do the link commands by hand, and
substitute the correct link command using autoconf. When
something doesn't work, its fairly obvious what's not working,
and you don't have to look through hundreds or thousands of
lines of poorly documented script code to fix somebody's
linux-ism (or bash-ism, which winds up being the same thing).
You’re making the fatal assumption that the person writing the build
rules is the person attempting to build it. Most of the build problems
I’ve had with shlibs would be trivially solved with libtool because
the original developer, although writing perfectly portable code,
wrote no specific build logic for the platform I was building on.
_You_ might support Darwin and Solaris, but plenty of developers have
neither the time nor inclination to bother with explicit support (and
what happens if I'm building on DragonflyBSD, or Interix, or HP-UX?)
Granted, you’re SOL if libtool has only embyronic (or no) support for
the platform itself, but then you’re still no worse off than the
developer of the software doing the same.
The problem is you're *worse* off if the developer of the software
relied on libfool, and libtool has no working support for your
platform. Hence my "never again" trip to into libtool land
to try to get our previous product to build on aix. It was
exactly the experience of porting to a new platform that led
us to avoid libtool in any future projects.
Anytime I ever see anybody using automake I just cringe.
I have problems getting even trivial projects to build unless
I use the exact same machine and path as the developer who
initiated the project. I guess there needs to be an auto-something
to make automake portable :)
I'd suggest that you (or whoever the developer is) are doing it very
*very* wrong :)
automake "just works" -if- used properly, and you don't attempt to
regenerate all the configure scripts and Makefile.ins using completely
different versions of autoconf/automake to the ones the project was
designed to use.
Bingo!
-building- an automake project is literally nothing more than
./configure [opts] && make && {sudo|pfexec|su -c} make install [opts].
it's only if you start changing how it works that you actually need to
care that it’s automake, except for the fact that you can rely on,
e.g., DESTROOT being honoured during a “make install”, and “make
distclean” doing the right thing.
That's only if the developer checks in the machine generated makefiles.
Many open source projects don't do that. The most recent build
disaster I had was with ethtool. It was literally faster to write
a Makefile from scratch than figure out what automake was objecting to.
This is somewhat off-topic by now, though, but having used autotools
Very offtopic.. Let's end it here..
Drew
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden