visual studio and git

Levi Pearson levipearson at gmail.com
Thu Nov 7 09:29:00 MST 2013


On Wed, Nov 6, 2013 at 4:11 PM, Charles Curley
<charlescurley at charlescurley.com> wrote:
> On Wed, 06 Nov 2013 15:38:50 -0700
> Daniel Fussell <dfussell at byu.edu> wrote:
>
>> Whats wrong with the gnu toolchain?  I'll admit that I write my
>> makefiles by hand, and recently I've been doing more writing in VHDL,
>> so I'm somewhat lacking in experience.  Whats wrong with autotools
>> and gcc in particular?
>
> Autotools is reputed to be an unholy mess, and very difficult to
> maintain. I have never been able to understand how the whole tool chain
> works. The lack of documentation didn't help either.
>
> There are alternatives, such as scons.

Although I agree in general that the implementation of autotools is an
unholy mess, I just want to point out that the "user interface" for
the developer is far simpler than the generated makefiles that ship
with release tarballs might suggest, and it's got reasonably good
documentation on how to use it.  If you consider the world it was
developed in, where every UNIX-like system had vastly different sets
of available system libraries, it provided a *huge* advantage over the
typical manually-managed makefile. It's also pretty well-maintained,
so if you're largely targeting POSIX systems and you can ignore the
fact that it's implemented via a gigantic pile of M4 macros, it's
still a good solution for writing portable/configurable code in C.

There have been some significant advances in build systems lately, but
autotools is still the king for portable POSIX-based free software
projects.  There's value to using a well-supported build system if you
intend to have your software distributed widely.  But if you are doing
something either very small or not intended for distribution, or
something that is massive enough to push the limits of what GNU make
can deal with efficiently, by all means look for a build system that
better suits your needs.  There are *many* of them available now, but
in the time you might spend learning enough about the alternatives to
make an informed decision as to which best suits your needs, you could
have learned how to use autotools, which is a good thing to know even
if you don't end up using it as your primary build configuration
manager.

TLDR: Autotools is old and crufty, but then so is
POSIX/UNIX/Linux/vim/emacs, and you're still using some of those! An
honest look at your needs and the value provided by autotools may
still make it the best solution for many users, but if you do need
something else, there are great alternatives to meet specific needs.


More information about the PLUG mailing list