Some thoughts on the modularization effort

Shawn Starr shawn.starr at rogers.com
Wed Mar 30 20:05:42 PST 2005


On March 30, 2005 22:55, you wrote:
> > if COMPILE_LSF
> > lsf = clumon_lsf
> > endif
>
> Thereby creating a dependency on GNU make. You could have written it
> more portably, in a Makefile,in, as something like:
>
> @COMPILE_LSF at lsf = clumon_lsf
>
> And then in your configure.in, if you dont want to COMPILE_LSF to
> be true, you AC_DEFINE it to #. That way you get the conditionals
> working in the Makefile without creating a dependency on a specific
> tool.
>
> For the project you are working on, that dependency may not be an
> issue. But for X.org, which curently works on hundreds of systems,
> not all of which use GNU make, forcing a dependency on GNU make
> would be a regression. If thats acceptable, so be it.

Well, the project im working on yes it's generally GNU make centric (Though it 
is not Linux specific so this will need to change). We don't want to get 
caught having to depend on GNU make to build X and friends. But I'll leave 
that to the powers to decide on what formatting we want to go with.

> > You assume developers don't want to rebuild the .in files or run an
> > autogen.sh which would rebuild it all.
>
> Not really, I just know from experience its a pain in the butt.
> The project maintainer has autoconf 1.8.5, I only have 1.8.4.
> The makefiles work for him, they don't for me. Now I have to
> upgrade system level tools just to work on adding a small change?
> I know thats become common practice, its just not very *good*
> practice (IMHO).

> Kean

Yes, that can/is a pain,  but we should standardize on some versions and keep 
that consistant. Something that seems to be already available on most unix 
platforms and for Win32 systems.

GNU Auto* isn't perfect, Imake sure isn't either :(

Shawn.


More information about the xorg-modular mailing list