Some thoughts on the modularization effort

[Shawn Starr]

On March 30, 2005 19:15, Kean Johnston wrote:
> ... but my suggestion would be to
> have an xorg.m4 that we maintain, that platform maintainers can
> tweak and autodetect (or in cases where its appropriate,
> simply platform-detect) and set up macros like DLLDFLAGS, DLLD,
> DLCFLAGS etc. This allows for much greater scope in platform
> flexibility, and avoids many of the somewhat arbitrary and
> rigid libtool rules like their crazy version numbering scheme,
> *huge* shell script to execute on every compile or link etc.

From what I've been hearing/discussing we'll be likely using pkg-config to 
handle not require a massive .m4 for autodetection.

> The second case, automake, I just don't believe is necessary.
> It produces extremely verbose and difficult to diagnose Makefiles.
> I've written some pretty huge autoconf type things in my time
> and never once encountered a situation where automake would
> have done things either better, or quicker. Maintaining a
> Makefile.in isn't that hard. Its also a lot easier to debug.
> With a Makefile.am, the makefile that make uses is two levels
> removed fromt he source. With a Makefile.in its just one.
> Also, but just using a Makefile.in with some well documented
> standards, you gain considerably more flexibility. If you use
> automake, you are locked into their way of thinking, and for
> a project as complex as X, the more flexibility you have the
> less its going to cost you to implement.

> Kean

I would argue that Automake makes things easier. I'd rather not spend all my 
time working on Makefiles, there's a lot more to do. Automake just gets it 
done. I *never* touch Makefile.in files, if I need the .in file to have 
functionality that isn't present when its generated, I stick this into 
the .am

Case in point (from the clumon project im a developer in):

What if I want dynamic compliation? say I don't want to build test binaries 
that some X libs may include (--disable-tests). Why would I want to wade 
though a Makefile.in? It's so much easier, don't make it harder :)

configure.ac:
...
AM_CONDITIONAL(COMPILE_LSF, [test x"$HAVE_LSF" = xyes])
AM_CONDITIONAL(COMPILE_PBS, [test x"$HAVE_PBS" = xyes])
...

Makefile.am:

if COMPILE_LSF
lsf = clumon_lsf
endif

if COMPILE_PBS
pbs = clumon_pbs
endif

sbin_PROGRAMS = clumond
bin_PROGRAMS = clumon_post clumon_pcp clumon_pcp_c $(lsf) $(pbs)
clumond_SOURCES = clumond.c
clumond_LDADD = -lmysqlclient @ZLIB_LIBS@

clumon_pcp_c_SOURCES = clumon_pcp_c.c
clumon_pcp_c_LDADD = -lpcp -lmysqlclient @ZLIB_LIBS@

clumon_pcp_SOURCES = clumon_pcp.c
clumon_pcp_LDADD = -lmysqlclient @ZLIB_LIBS@

if COMPILE_LSF
clumon_lsf_SOURCES = clumon_lsf.c
clumon_lsf_LDADD = -lbat -llsf -lmysqlclient @ZLIB_LIBS@
else
clumon_lsf_SOURCES =
clumon_lsf_LDADD =
endif

if COMPILE_PBS
clumon_pbs_SOURCES = clumon_pbs.c
clumon_pbs_LDADD = -lpbs -lmysqlclient @ZLIB_LIBS@
else
clumon_pbs_SOURCES =
clumon_pbs_LDADD =
endif

clumon_post_SOURCES = clumon_post.c
clumon_post_LDADD = -lmysqlclient @ZLIB_LIBS@

You assume developers don't want to rebuild the .in files or run an autogen.sh 
which would rebuild it all. 

Shawn.