Re: newby question: to use or not to use ?

[Baurzhan Ismagulov]

On Thu, Jul 05, 2007 at 03:30:31PM +0100, Joao Miguel Ferreira wrote:
> The code is some kind of communications middleware in C/C++. From it we
> build some shared libs which are loaded by our client's application
> developers.
> 
> I've used Autoconf/Automake and Libtool before but it was a very short
> (but good) experience on Linux only systems.

> 1- should I go ahead and try to unify development/maintenance around the
> GNU Autotools for the UNIX/Linux systems (what I have know is a src dir
> and CVS with a bunch of platform specific Makefiles ?!?!)

Hmm, you should decide yourself. In general, if you don't have a
concrete problem and your boss hasn't asked you to enhance the build
system, it may be unclear to him why he should pay for it.

That said, in my current project autotools certainly save costs, but
this is not easy to quantify, since without them we probably wouldn't
invest more time in maintaining the build system, just our home-brewed
makefiles would be of much lower quality than autotools provide out of
the box.


> 2- what pitfalls could there be

My biggest problem was building applications from many components in
different repositories. The way it had been done was to prescribe
checkout paths and to look for headers / libs in predefined locations.
I've tried to do that with autotools, but in the end we adopted a
package system and dropped path dependencies.


> (ex: could the source code we have be such a mess that it would stop
> me from continuing, along the way ?

Usually, the problem is not that you can't do something with autotools,
but that you can easily spend much time looking for a way to do a
specific thing.


> could something compiled with gcc not be compatible with client's
> applications compiled with some specific compiler ?;)

Name mangling and structure alignment are some of the things to watch
out. You have to check your specific requirements.


> 3- Are the autotools/gcc 'smart enough' to cross-compile correctlly to
> each of the targets

This is what autotools are really strong at, although I can't say
anything about the effort necessary to add a platform to autoconf if it
doesn't support one.


> My feeling is that 'porting' to Autotools is good and will show profits
> in the future, but my boss won't let me do it unless I find more
> 'measurable' advantages...

I like the following features the most:

* Cross-compilation support
* Building in another directory
* Targets like clean, distclean, etc.
* Ease of adding new binaries and libraries (both internal and external)
* Testing framework integration

For us, these features do save costs in the long run; the configuration
files are much more maintainable than custom shell scripts and
makefiles.

As I said above, the main difficulty is to understand how all this works
and to figure out how to do a certain thing -- this may be very
time-consuming.


With kind regards,
-- 
Baurzhan Ismagulov
http://www.kz-easy.com/