Re: [xougen] Weigelts new build system

[weigelt]

On Fri, Sep 12, 2003 at 03:06:06PM -0700, Jonathan Walther wrote:

> Weigelt, your system sounds interesting.
thx.

> Can you explain quickly and simply, how does it let you add support for
> different build environments on different system?  
There are different points.

a) General build process (compiler handling, etc):
--> mostly part of the node handlers (each node has an class which
    defines the handling functions) or in the build systems's 
    platform profiles.
    
b) package structure
--> some platform dependent packages consist of multiple parts, which
    apply to several build variants such as target platform.
    
    i.e. we have source pool nodes which are only active on some 
    platform(s).
    
--> non-platform-modules only rely transparently on the platform-modules.
    i.e. filesystem stuff: the other modules just import an module "fs",
    which supplies (platform independent) filesystem functionality. 
    evrything's hidden behind it. no more #ifdef __WIN32 ;-)
    (look at the (older?) xmms code - they did it as wrong as possible ;-))


> How does it help you modify the header files and source files appropriately, 
> depending on which system it is destined for?  
As mentioned above. We have very strict module structures (but they dont
need to appear in binary stage - modules are just existing on source level)

If we have some functionality, which has to implemented differently on
several platforms, we put all this stuff into an separate module or sourcepool
which exists in multiple variants and then let the builder decide what to do.

<snip>
> How does it allow us to cross-compile the code quickly and easily so we can 
> compile the code for old Sun Sparcstations on our snazzy Athlon64's?

That's the task for the compiler settings. Each node type has handlers which
do an quite clear set of tasks. What really happens is hidden from the 
developer/user, just what comes out is important. 
For most platforms it will be okay working with different settings for 
the compilers, but sometimes it may be necessary to implemement new
node handlers. Thats the reason why i would prefer implementing the whole
stuff in an script language like perl or php. (later fast C implementations
can follow and perhaps use external subsets of the scripted implementation)

>From the view of the user, the compiler settings can be defined by some 
kind of stylesheets. Here you can define things like code optimization,
target platform, install locations, ... If we need an debug build:
pull over the debug stylesheet - if we need an release build: pull over
the release styleseet, ... if we need platform B, simply pull over the
stylesheet for target B. With this technique we also can specify some 
exotic things like linking some libs statically (or perhaps directly
compile in), use import other module versions, let out some parts, ...

If you try something that's not supported or requires something
(i.e. newer libversions), the builder will tell it before anything
other is done. So you i.e. never have compilation failing somewhere
in the middle because somethings missing or too old. You all see it in 
the prepar stage - and this data is machine readable and could be used
for automatic external preparation like fetching/installing required
packages.

<snip>
> GNU automake and autoconf seem to try to make both the source code and
> the build system portable together.
> 
> imake doesn't seem to have a feature to auto-detect what system it is
> on, while autoconf and automake do have this.
Such an auto-dection like automake does is completely wrong, since it 
fails quite often (and once it fails, its completely unusable) and bloats
up the code. The automake input is not usable for other purposes than
just compiling and installing somewhere and it also requires an human
user at many points. But it cannot be used for fully automated package
dependecy and system integrity checks, automated upgrades, quality checks,
modularity and teamwork and other things which are important in 
professional software development.

It's nothing more and nothing less than an set of little helper macros.


<snip>
> How does your scheme detect what system it is on, and how do you tell it
> how to compile programs on a particular system?
It does not detect it - is it simply _defined_. 
Either the user specifies an specific configuration or it uses an global
database. There it also finds all necessary information from other packages
imported by the package to build.

<snip>
> As a front end interface to programs like imake and the autotool suite,
> your build system would be very nice.
No. If you want to do this, you didnt understand where I want to go.
The interesting information in both imake an automake input files are 
not clear enough, but especially automake input is full of redundant
information we do not need nor want to have. And both systems are too C 
and unix centric. With my new system I also want to build completely
different things varying from java,oberon,compiled php to tex documents.

Perhaps some parts of automake (namely the check/detect routines) can be 
used for helping with the generation of the platform dependend 
builder settings. This is somehow a little bit of recycling ;-)


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT services

 phone:     +49 36207 519931         www:       http://www.metux.de/     
 fax:       +49 36207 519932         email:     address@hidden
 cellphone: +49 174 7066481          
---------------------------------------------------------------------
 Diese Mail wurde mit UUCP versandt.      http://www.metux.de/uucp/