Modularization mailing list and initial strawman proposal

[Shawn Starr]

Some random bits of points from this thread:

Daniel Stone wrote:

> The problem is thus: there are some really bad points about imake (like
> a total lack of interactivity and basic language primitives needed to
> execute tests), but on the whole it's not a horrifically bad build
> system.  The problems with it are several:
>         a) no-one knows it, not necessarily because it's obtuse (so are
>            the inner workings of autotools, scons, or whatever's cool
>            this week), but because no-one else but us uses it;
>         b) we have to maintain platform definitions, which is, to put it
>            bluntly, total crap.  it shouldn't be our job, that's the job
>            of the platform maintainers, who know it far better than us;
>         c) no-one knows it;
>         d) no-one knows it.
> 

I can certainly help with porting efforts. I've been very intimate with Imake 
in the past and I use the Autotools a lot.

> autotools has many advantages in terms of functionality, simplicity, and
> having platform definitions maintained by people who know the platform
> inside out; not us.  People feel comfortable working with autotools,
> because it's familiar territory.  No-one feels comfortable with the
> spaghetti imake horror we've backed ourselves into.

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.

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.  

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.

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 ]

The proposal looks good, other than some issues addressed on IRC, I support 
this process. There may be some tweaks made to it, but the overall goal is 
one I support.

Shawn.