debian package for the up-comming 0.14 version

Thu Aug 6 16:00:00 UTC 2009

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. :)

> It is true that when you clone a repository, the 'master' branch has a
> special meaning. So maybe having this master branch reflecting the
> stable version of lissac could help peoples have a nice experience with
> the git repository of lisaac.
I think actually it's the HEAD that is important. We'll just have to say
that the HEAD points to the stable branch.
> Then you propose to add into the next branch each stable
> features added for the up-comming version release of lissac.
>
> That way you have all the time a stable version working out of the box
> in the master branc and a developpement version in the 'next' one also
> working out of the box with new features.
>
> this process means thah someone should have to decide which feature is
> ready for the next version and merge it.
Benoit probably.
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.
>
> you can just create a tag for the version then if someone needs to
> correcte a bug you just have to checkout this tag and start a new
> branch from here.
> in fact you should push bug correction to the head of master because it
> always propose the current stable release of lisaac.
> finally you will see that all those 0.x branches are useless :)
We'll see.
I already modified a bit the 0.13.x branch ...

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 ...

And don't forget we have git cherry-pick.
>> And for branch per topic, I also agree. I'm currently working on the
>> .lip files in the compiler and I have changed things quite a bit in
>> here. I'll talk more about it later, but if you want, there is a
>> branch mildred-projects that I work with.
>
>
> Can you explain to me what is the advantage of this .lip files compare
> to an integrating of the lisaac compilation process into the well known
> autotools. Maybe I am missing something here. And that both could be
> complementary.

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 ?)

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.

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 file
    * Second: run gcc: this is the back_end slot in the lip file

      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.

      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

This is not on master yet, I hope it'll find its way here after the
bootstrap.

Mildred

-- 
Mildred Ki'Lya
╭───────── ｍｉｌｄｒｅｄ５９３＠ｏｎｌｉｎｅ．ｆｒ ──────────
│ Jabber, GoogleTalk: <mildred at jabber.fr>
│ Website: <http://ki.lya.online.fr>           GPG ID: 9A7D 2E2B
│ Fingerprint: 197C A7E6 645B 4299 6D37 684B 6F9D A8D6 9A7D 2E2B

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/lisaac-devel/attachments/20090806/556ece32/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/lisaac-devel/attachments/20090806/556ece32/attachment.pgp>