debian package for the up-comming 0.14 version

[Picca Frédéric-Emmanuel]

Le Thu, 06 Aug 2009 18:00:00 +0200,
Mildred Ki'Lya <ml.mildred593 at gmail.com> a écrit :

> Hi,
> 
> On 08/06/2009 09:19 AM, Picca Frédéric-Emmanuel wrote:
> > ok then it will propose a .c version of the compiler for the
> > distribution. And the make process will propose to compile this .c
> > version to re-compile lisaac using rela lisaac code of the
> > compiler :).
> 
> If you want to make it simple, you'll just have to compile the .c
> version. :)

yes but compiling lisaac using lissac is to my opinion a better test of
the lisaac compiler :).

even better if we can compare the .c code of the compiler generated by
lisaac.c and the code generated from the lisaac compiled from lisaac :)

> I just hope he can use this development model. Now, he is just
> breaking everything to add cool new features that will work a few
> years later. The current compiler is now around two years old in that
> respect. We'll have to RESTRAIN ourselves from breaking everything.

do not restrain :) just use branches for the developpement.

> When we fix a bug and create a minor version, you may not want all the
> new (unstable) features that are in the branch master ...

Yes this is why the next branch exist. the next branch is a sort of
stage area (like the git one) and when this one is ready hop merge into
master.

So master is always the stable version with bug correction
next is for features stable enought to be include in the futur stable
version.

other branch are for developpement.

just have to keep in mind not to break master with developpement stuff.
And to be sure that next features are mature enought :)
 
> And don't forget we have git cherry-pick.

Yes, I am not a fan of this things :)

> I absolutely HATE the autotools.
> 
> Not quite as much, but I don't like them at all. (Why do you think I'm
> also working towards a replacement to make ?)

there is plenty of other replacement for autotools
cmake, scan, waf (I like it a lot)...

> Now, I think that the lip files can't replace the complete build
> process for complex projects. Complex projects will have lisaac code,
> C code and perhaps something else as well. But for now, Lisaac works
> on its own (like it always has) and try to do everything.

maybe we can inspire our self of the way vala was integrated in the waf
build system. Thaht provide already all the infrastructure to compile
C/C++/vala/fortran

(vala have the same problematic than lisaac, it produce .c and .h files
thaht you need to compile)

http://code.google.com/p/waf/

> The lip files are doing two things:
> 
>     * First: set up the paths where the compiler will look for the
>       prototypes (*.li files). This is the front_end slot in the lip

this can be a special tool for waf to do this

> file
>     * Second: run gcc: this is the back_end slot in the lip file

this comes for free because all this is already implemented in the waf
build system.

>       Back End
> 
> I do agree with you, Lisaac shouldn't attempt to do everything on its
> own, and more important, should be able to integrate nicely with
> building tools (whatever that may be, autotools, make, scons, Jam,
> TBuild ...)
> 
> But with .lip files, it means that you can implement for yourself what
> exactly you want lisaac to do. If you want lisaac to leave the .c file
> and not run gcc on it, just don't call gcc in your .lip file.

I understand that learning lisaac by writing a need build system can
have an academic interest :)

>       Front End
> 
> What I changed is the front_end. Until now, things worked by listing a
> series of absolute paths where you can find .li files, that's all.
> 
> What I did was to allow using relative paths (relative to the .lip
> file), and enabeling lip files to load others lip files and access the
> prototypes they defined.
> So for example
> 
>     * Before you had all the library paths defined in the main
> make.lip file and another lip files inherited from it to add paths to
> it. There was no priority between the different paths. If two
>       prototypes had the same name, you almost couldn't tell which one
>       would be chosen. The only way out was to specify the directory
> in the source code like: DIR...PROTOTYPE
>     * Now, you have the main .lip inheriting the global make.lip and
>       loading lib.lip. lib.lip is defining the paths for the standard
>       library. When two prototypes have the same name, the prototypes
>       from the main project has a higher priority than the prototypes
>       from the library. The library can be named and you can use this
>       name to specify the prototype in the source code (for example
>       STD...PROTO if the library was named STD in the .lip file, you
>       could have called it STDLIB or whatever you like, you are not
>       limited by the filesystem)
> 
> Now, this is my use-case for this feature:
> 
> We have a project we call MAIN. There is a library LIB that comes in
> two versions: LIB1 and LIB2.
> Now, we have two others libraries that are directly used by the
> project MAIN:
> 
>     * LIBA needs LIB in the version 1, and at the time LIBA was
> written, only one version of the library existed. So in the source
> code, all the prototypes from LIB are written like: LIB...PROTOTYPE
>     * LIBB needs LIB, but in the version 2. Unfortunately the
> programmer was not careful and prefixed all the prototypes from LIB
> v2 using LIB (LIB...PROTOTYPE).
> 
> Now, we have a potential problem. LIBA and LIBB both use the LIB...
> prefix to access each a different code. If we depend on the
> filesystem, LIB... can only prefix the same version of the library
> and we can't use both LIBA and LIBB.
> 
> If when we import the library we specify its prefix, and if its prefix
> is not global to the whole program but only local to the project that
> use this library, we can use both LIBA and LIBB

I need to think about this with a coffe or a camomille :)

Have a good week end and enjoy coding with lisaac

See you

Frederic