Modularization mailing list and initial strawman proposal

[Kevin E Martin]

On Wed, Mar 30, 2005 at 02:43:37AM -0500, Shawn Starr wrote:
> I can certainly help with porting efforts. I've been very intimate with Imake
> in the past and I use the Autotools a lot.

Sounds great.  Glad to have your help.  It looks like we are just about
ready to send this proposal to the architecture working group.  I'll be
making the updates to the proposal that we have discussed on the mailing
list this afternoon, so if there are things that you would like to see
me add, please let me know soon.

> Imake is ugly, we all know this.  the Autotools handle a lot of nice things 
> that we did manually in the Imake macros. One danger is to make sure your 
> Makefile.am syntax conform to BSD Make at a minimal so that other UNIXs 
> will work still. Since Automake.in builds BSD friendly(?) Makefiles.

This is good info, and we should make sure to add it to the transition
guide mentioned in the proposal.

> Adam Jackson wrote:
> 
> > Technically this is a style issue.
> > 
> > My understanding of autoconf is that there's a difference between --with-foo 
> > and --enable-foo.  The --with form is used for features that have external 
> > dependencies, whereas --enable is for features that do not.  So for example, 
> > we would say --with-freetype but --enable-render.
> > 
> > The easy rule is --enable options default to on and --with options default 
> to 
> > off.  This is too simplistic of course.  The reality is that we'll need to 
> > set sensible defaults and make sure that we don't add --enables that are 
> > really --withs.  But this is not different than under imake.
> > 
> > That other projects get it wrong doesn't mean we will too.
> 
> We should have a design document explaining the standards and naming schemes 
> for the configure options as you mention above.  

Yes.  This is part of what I want to see in the transition guide.  It
should help to guide people around the pitfalls that we've found,
provide standards and naming schemes, explain how to build the system,
etc.

> Consistant
> - configure script options is critical.
> - macro styles, variable names makes code easy to read.
> - configure.ac scripts
> - Makefile.am templates.
> - *.in templates and such
> 
> - *** Consistant API M4 macros you don't want to get into an autoconf/automake
> mess.
> We need to make sure we pick a computable version that most platforms already
> can use.
> 
> Creating a Wiki and or a document on how to build Xorg for testers/developers
> to get involved is important.

Yes, see above.

> Other notes:
> 
> If we decide to standardize on jhbuild as the 'official' build mechanism, we 
> should make sure it can handle developers needs.
> 
> 1) Don't force jhbuild to set $prefix to be $HOME for everything. This is one
> gripe I have :). It should be flexable for developers/testers.
> 
> 2) [ Fill in your gripe/wishlist here ]

I think this is good, and I'm sure that during the modular development
phase we will find other ways that we can enhance jhbuild and the build
system.

Thanks,
Kevin