Re: [xougen] Weigelts new build system

[weigelt]

On Wed, Sep 10, 2003 at 03:25:53PM -0700, Jonathan Walther wrote:

<snip>
> Weigelt, your new build system sounds interesting.  
:) 

> Can you describe it to us?
Well, I didnt write down any useable documentation yet, so I try to 
explain my ideas "out of the head" ;-)

The main idea is, we only describe what the software consist of, not 
thinking anylonger about how to build it (its not the job of the developer,
but the build system)

Lets take an very small example: We have an simple application --> Xclock.

What code do we need ? Okay, lets say, we have 3 source files in C:
timer.c, widget.c, main.c. Also we've got some include files: timer.h, widget.h
All we want to get out is an plain executable.

To let it work, we also need to link against libx and include its headers, etc.
Okay, so we _import_ an module Xclient, which does it. (take care of the
vocabulary: importing and linking are completely different - imports are
defined by the developer, but linking is done by the build system)

hmm, now our simple project description could look like:

module "xclock"
{
    type "executable";
    source "timer.c";
    source "widget.c";
    source "main.c";
    header "widget.h";
    header "timer.h";
    import "Xclient";
};

What can the builder learn from it ? 

* <type>   we want to get out an binary executable.
* <source> compile timer.c, widget.c, main.c and link them together to xclock.
* <header> use widget.h and timer.h as dependencies 
* <import> learn from the Xclient's interface description, what's needed to
           get it in. (i.e. link against libx and add include path)

Some tools (i.e. in an IDE) could do some nice things, i.e. looking at
included header files and adding them as autodep-nodes to the project:

module "xclock"
{
    type "executable";
    source "timer.c"
    {
        autodep "<sys/timer.h>" @sys:libc;
        autodep "<stdio.h>"     @sys:libc;
        autodep "<unistd.h>"    @sys:libc;
        autodep "timer.h";
    };  
    source "widget.c"
    {
        
        autodep "<X11/x11.h>" @x11:Xclient;
        autodep "<stdio.h>"   @sys:libc;
        autodep "<unistd.h>"  @sys:libc;
    };
    source "main.c";
    {
        autodep "<X11/x11.h>" @x11:Xclient;
        autodep "<stdio.h>"   @sys:libc;
        autodep "<unistd.h>"  @sys:libc;
        autodep "widget.h";
        autodep "timer.h";
    };
    header "widget.h";
    header "timer.h";
    import "Xclient";
};


Also we have to support library modules. Those ones can be built and
put somewhere, so other modules can import this. The developer still
only comes in touch with the module's high level interfaces, but not 
with concrete locations, file format, etc.

module "clocklet"
{
    type "library";
    source "timer.c";
    source "widget.c"
    header "widget.h";
    header "timer.h";
    header "clocklet.h" { export public; }
    import "Xclient";
}

As we see, we've got something new: an header file which is marked for
export. This file will be installed somewhere to the global include 
directory, i.e. /usr/include/X11/clocklet/. It doesnt really matter to
the developer, where it will be - the builder will know it from the package
runtime configuration, which will be generated/added on install.

Now let's do something more complex: a project with one executable and
two libs. (i've left out some unneeded text ...)

package "multimedia/esound"
{
    module "esd"
    {
        type "executable";
        import "esound_common";
        ...
    };
    module "libesound"
    {
        type "library";
        import "esound_common";
        ...
    };
    module "esound_common"
    {
        type "library";
        buildstyle "static/inline";
        ...
    };
};

Huh, whats "esd_common" ? hmm, nice, we have an library which does not
produce and so file, but only bundles some code shared between the two
other modules. 

If we someday need it as an separate library, but do not want to touch
the original, we could build an wrapper around it, which makes an .so
out of it.

module "libesound_common"
{
    type "library";
    imports "esound_common"
    {
        inherits "*";
    };
};


> Have you implemented it anywhere?  Can we see it in operation
> anywhere?
No, not yet. It just exists in my mind and on some sheets of paper.

<snip>
> To be able to give your system serious consideration though, we need to
> know that you understand the Imakefile system used by X11.  

Well, I dont fully understand it by now, but I can imagine, what it does.
The imake files are quite good, but do not contain all the information
I want to have in there. Think of interface definitions in my examples,
such things seem to be really missing in imake files. On the other side
some information in the imake files are too concrete.


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/