Modules build framework/autoconf-2.13

Modules build framework/autoconf-2.13

[Borsenkow Andrej]

Here is suggested change in modules build procedure. It does not strictly
speaking require autoconf-2.5x but it makes it much more easier and
consistent.

Every module is locate in own subdirectory. .mdd file specifies

- usual stuff (dependencies, file, etc)
- Makefile.in fragment
- configure.in fragment

preconfig script walks source directory and in every directory with *.mdd
creates

- Makefile.in (using standard template and adding fragment from .mdd)
- configure.in ( -"- )

preconfig also collects names of all subdirectories and adds them (via
inclusion) to top-level configure.in that is then using it to recursivly
call generated module's configure. Then it runs autoconf to create configure
in all subdirectories.

preconfig may optionally generate config.modules in source directory so
users have some example; config.modules in build directory overrides
(augments) it. To skip some modules at configure time it is possible to
generate dummy entry in Makefile (by configure.in fragment) that would just
print a warning without doing anything.

The main goal is to make adding new modules as non-intrusive as possible.
Modules come with own configure if needed so there is no need to modify
top-level configure every time; still (owing to autoconf 2.5x) you can list
help from all modules and pass needed parameters. This also (theretically)
allows you to have modules in separate tress from Zsh tree.

It does requires you to rerun preconfig it is all that is needed (autoconf
etc will be run automatically). It also should hopefully simplify makefiles.


Comments?

-andrej

Re: Modules build framework/autoconf-2.13

[Peter Stephenson]

Borsenkow Andrej wrote:
> Here is suggested change in modules build procedure. It does not strictly
> speaking require autoconf-2.5x but it makes it much more easier and
> consistent.
> 
> Every module is locate in own subdirectory. .mdd file specifies
> 
> - usual stuff (dependencies, file, etc)
> - Makefile.in fragment
> - configure.in fragment
> 
> preconfig script walks source directory and in every directory with *.mdd
> creates
> 
> - Makefile.in (using standard template and adding fragment from .mdd)
> - configure.in ( -"- )
> 
> preconfig also collects names of all subdirectories and adds them (via
> inclusion) to top-level configure.in that is then using it to recursivly
> call generated module's configure. Then it runs autoconf to create configure
> in all subdirectories.

Sounds quite reasonable.  It might make it more difficult to handle
problems with include file location and dependencies on other modules,
but that's currently not all that robust.  Possibly the directory
structure could reflect this, dependencies living in higher directories.
(Doesn't help multiple dependencies, though.)

It would be neatest if it were possible to add an new module and add its
tools without regenerating the whole set, i.e. looping over separate
configure files rather than appending them to the main one.

Subdirectories ought to be subdirectories of Modules, not directly of
Src.  I don't know what would happen with Zle.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

RE: Modules build framework/autoconf-2.13

[Borsenkow Andrej]

> 
> Sounds quite reasonable. 

Oh well :-)

> It might make it more difficult to handle
> problems with include file location and dependencies on other modules,
> but that's currently not all that robust.  Possibly the directory
> structure could reflect this, dependencies living in higher
directories.
> (Doesn't help multiple dependencies, though.)
> 

What I plan is to first collect modules list then sort them before
generating Makefile.in's. This way you know all dependencies in advance
(or dependencies loop for that matter).

> It would be neatest if it were possible to add an new module and add
its
> tools without regenerating the whole set, i.e. looping over separate
> configure files rather than appending them to the main one.
> 

Sure! That is what configure does. Of course, 2.5x does not cache by
default which means it will rerun the whole configure(s) (unless you
have told it to create cache).

> Subdirectories ought to be subdirectories of Modules, not directly of
> Src.  I don't know what would happen with Zle.
> 

The same. Move it as modules under Modules. It is not in any way
different.

Would it be O.K. to get rid of autoconf 2.13 compatibility? 

-andrej

Re: Modules build framework/autoconf-2.13

[Peter Stephenson]

Borsenkow Andrej wrote:
> Would it be O.K. to get rid of autoconf 2.13 compatibility? 

That's probably a good thing, since otherwise I'm liable to forget that
I intend to make 4.1 releases using 2.50+.  (Except it's a bit confusing
since I still use 2.13 for 4.0.)

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK                          Tel: +44 (0)1223 392070


**********************************************************************
The information transmitted is intended only for the person or
entity to which it is addressed and may contain confidential 
and/or privileged material. 
Any review, retransmission, dissemination or other use of, or
taking of any action in reliance upon, this information by 
persons or entities other than the intended recipient is 
prohibited.  
If you received this in error, please contact the sender and 
delete the material from any computer.
**********************************************************************

Re: Modules build framework/autoconf-2.13

[Bart Schaefer]

On May 8,  3:56pm, Borsenkow Andrej wrote:
}
} Would it be O.K. to get rid of autoconf 2.13 compatibility? 

Well, I'd rather you didn't, but I'm a throwback to the stone age because
I insist on using this email program I wrote that will stop working if I
upgrade my operating system ...

Nevertheless there are a lot of RedHat 6.2 systems out there and RedHat
has not seen fit to upgrade the autoconf RPM for it, so you're likely to
generate a lot of "why can't I build zsh?" questions from people who try
to use the latest CVS stuff from sourceforge.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

RE: Modules build framework/autoconf-2.13

[Borsenkow Andrej]

> On May 8,  3:56pm, Borsenkow Andrej wrote:
> }
> } Would it be O.K. to get rid of autoconf 2.13 compatibility?
> 
> Well, I'd rather you didn't, but I'm a throwback to the stone age
because
> I insist on using this email program I wrote that will stop working if
I
> upgrade my operating system ...
> 
> Nevertheless there are a lot of RedHat 6.2 systems out there and
RedHat
> has not seen fit to upgrade the autoconf RPM for it, so you're likely
to
> generate a lot of "why can't I build zsh?" questions from people who
try
> to use the latest CVS stuff from sourceforge.
> 

I'd say those who build from sourceforge CVS can just as well install
autoconf from GNU tarball ... 2.53a even passed _all_ !!! tests on my
system - it is the first time ever.

I know your feeling about it which makes me just more reluctant to start
...

-andrej

Re: Modules build framework/autoconf-2.13

[Bart Schaefer]

On May 8,  8:01pm, Borsenkow Andrej wrote:
}
} I know your feeling about it which makes me just more reluctant to start

Don't use my feelings about it as the gating factor.