FreeTDS Development Group

[Frediano Ziglio <freddy77 AT gmail.com>]

Il giorno mer, 02/01/2008 alle 18.17 -0500, James K. Lowden ha scritto:
> Frediano Ziglio wrote:
> > > This has worked for many months at least.  What system complains about
> > > += in a Makefile?  I use BSD make with no problem.  
> > 
> > If I reminds correctly only = is standard make... but perhaps I confuse
> > += with :=.
> 
> I see.  Learn something new every day.  
> 
> This was a very small change, and the Makefile remains understandable even
> though the definition of bin_PROGRAMS is a little redundant.  No problem. 
> 
> 
> In general, I think it's impossible to write a Makefile.am that will work
> with "standard" make.  A standard, Platonic make doesn't exist.  We're
> constrained by what Automake produces, and we promise only BSD and GNU
> make.  
> 
> My feeling is that if it works with those two, we're covered.  Anyone with
> a lesser make can always install GNU make.  It has no dependencies and is
> available in binary form for practically every platform that has a Bourne
> shell.  He'll probably need it anyway to build other projects.  
> 
> But I can learn.  If you're lurking and I'm overlooking something, please
> chime in.  
> 
> BTW, I read "recursive make considered harmful" last night.  Interesting
> reading, could be applied to FreeTDS.  
> 

Really interesting. What surprised me most is the year! The author
deprecated "old method" in 1996 suggesting some make options more than
11 years ago!

The author give a clean example but it forgot some problems:
- integration with different tools (Automake, autoconf and so on)
- separation. This is a big clue if we agree to apply (I hope after a
release!) this stuff. Consider the line

LIBS += -ly

easy but LIBS is a global macro so all programs and libraries compiled
will link to this library... not that fine, in our project this would
lead for instance all libraries to require ODBC DM (even dblib or
ctlib). Currently there are many cheats to add different includes,
directory or libraries. 

Just to sum up if we want to improve our Makefiles breaking
compatibility IMHO it would be fine to embrace GNU make and write all
from scratch. For a single line however it's not worth.

Applying author rules to our project I must say that it's right... If
you change for instance include/tds.h and you issue a make in src/odbc
directory libTDS is not (correctly) rebuild... If you change directory
order in src/Makefile.am project to not compile (replacements must be
compiled before tds while dblib/ctlib/odbc have to be compiled after
tds). Not speaking about parallelism... you can't compile tds unittests
object before libtds for instance. On SMP machines (and/or multi-core) I
use -pipe but -j does not work that fine (and also -pipe does not help
that much, compiler spend most of the time you earn only cause you avoid
temporary file creations). I think that recursive build is correct in
highly independent directory (like a libz directory) where other
directories depends only on directory output and some includes (which
are detected by automatic dependency).

Honestly I "fixed" compatibility problem cause autogen.sh noted a
warning at that line; months ago it raise a similar problem due to
incompatible warning. This time error was due to a missing check on
configure.ac.

freddy77