new buildsystem -> first steps

[Enrico Weigelt]

Hi folks,


you already know I've got my daily heachache w/ the autotools 
stuff. ...

Meanwhile I've written my own libtool implementation in java
(in fact its an libtool-like frontend for unitool, my own 
toolchain abstraction).

And now I'm going some steps further:

I'm now in the process of defining models / schemata for declaring 
the *structure* of software modules instead of rules for building. 
Once the model is defined, I'll code the actual buildsystem, which 
does the whole building based no these trimmed down piece of data.

The idea behind is to take the control of the build process completely
out of the individual package and let it just provide enough data 
so that an external builder application can do it all. So the build 
process is completely out of the scope of interest of the package's 
developer - (he|she) only has to provide exact information to describe
the structure of the package. If someone wants to do some unusual 
builds (yeah, some people might consider crosscompile in an sysroot'ed
environment "unusual" ...), just the buildsystem has to be touched, 
not the individual package. This is an great help for distro maintainers.

Well, you might say, there are too many cases to consider in package
buiding, so my buildsystem has to be very universal (ie as make) and
thus quite complex. But it's meant to be neither.

That's why I work with different schemata, just like doctypes in the
SGML world but far more simplicistic (NOTE: a schema here is an verbal 
definition, like an RFC, not an formal one to be processed automatically. 
We don't wanna do things in the scale of XSLT etc ... we'll just have 
very few ones and so individual schema handling will be hardcoded 
at least in the first place).
I'll try to modelize the most common cases, eventually trimmed down 
a little bit, and define and implement an minimalistic schema for it. 

Let's start with a very simple (and not too seldom) case:
Header-Only packages.

We've got several packages, which only provide header files and probably 
some documentation - mainly they provide extensions protocol stuff.
They're our first exercise: just install some header and doc files,
and create some retrievable package information (aka .pc files)
No compilation, no code-generation, etc.

In example of compositeext the specification could look like this:

> @schema:			library/c/plain-headeronly-1.0
> library:			compositeext
> version:			2.0
> domain:			X11
> header-public-target-dir:	$(@@package-install-includedir)/X11/extensions
> header-public-source-dir:	$(@@srcroot)
> header-public-file:		composite.h
> header-public-file:		compositeproto.h
> package-name: 		CompositeExt
> package-description: 		Composite extension headers
> create-pkgconfig:		yes
> documentation-source-dir:	$(@@srcroot)
> documentation-target-dir:	$(@@package-install-datadir)/doc/compositeext
> documentation-file:		protocol
> maintainer:			keithp at keithp.com
> require-package:		xextensions
> require-package:		fixesext

(note: the ">" is for quoting in your MUA, not contents of the file ;-o)

This should be quite self-explaining. The "@" and "@@" in variable 
names are just a naming convention to indicate a special meaning.


Any comments to this ? 

Once we can consider this schema to be okay, I'll start coding the
handling for this schema and write package info files for this kind
of packages. 


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service
  phone:     +49 36207 519931         www:       http://www.metux.de/
  fax:       +49 36207 519932         email:     contact at metux.de
---------------------------------------------------------------------
  Realtime Forex/Stock Exchange trading powered by postgresSQL :))
                                            http://www.fxignal.net/
---------------------------------------------------------------------