<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
<tt>Hi,<br>
<br>
On 08/06/2009 09:19 AM, Picca Frédéric-Emmanuel wrote:<br>
</tt>
<blockquote
cite="mid:20090806091943.1818e95a@grisette.synchrotron-soleil.fr"
type="cite">
<pre wrap=""><tt>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 :).
</tt></pre>
</blockquote>
<tt><br>
If you want to make it simple, you'll just have to compile the .c
version. :)<br>
<br>
</tt>
<blockquote
cite="mid:20090806091943.1818e95a@grisette.synchrotron-soleil.fr"
type="cite">
<pre wrap=""><tt>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.
</tt></pre>
</blockquote>
<tt>I think actually it's the HEAD that is important. We'll just have
to say that the HEAD points to the stable branch.<br>
</tt>
<blockquote
cite="mid:20090806091943.1818e95a@grisette.synchrotron-soleil.fr"
type="cite">
<pre wrap=""><tt>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.
</tt></pre>
</blockquote>
<tt>Benoit probably.<br>
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.<br>
</tt>
<blockquote
cite="mid:20090806091943.1818e95a@grisette.synchrotron-soleil.fr"
type="cite">
<pre wrap=""><tt>
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 :)
</tt></pre>
</blockquote>
<tt>We'll see.<br>
I already modified a bit the 0.13.x branch ...<br>
<br>
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 ...<br>
<br>
And don't forget we have git cherry-pick.<br>
</tt>
<blockquote
cite="mid:20090806091943.1818e95a@grisette.synchrotron-soleil.fr"
type="cite">
<blockquote type="cite">
<pre wrap=""><tt>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.
</tt></pre>
</blockquote>
<pre wrap=""><tt>
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.
</tt></pre>
</blockquote>
<br>
I absolutely HATE the autotools.<br>
<br>
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 ?)<br>
<br>
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.<br>
<br>
The lip files are doing two things:<br>
<ul>
<li>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</li>
<li>Second: run gcc: this is the back_end slot in the lip file</li>
</ul>
<h3>Back End</h3>
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 ...)<br>
<br>
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.
<h3>Front End</h3>
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.<br>
<br>
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.<br>
So for example<br>
<ul>
<li>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<br>
</li>
<li>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)<br>
</li>
</ul>
Now, this is my use-case for this feature:<br>
<br>
We have a project we call MAIN. There is a library LIB that comes in
two versions: LIB1 and LIB2.<br>
Now, we have two others libraries that are directly used by the project
MAIN:<br>
<ul>
<li>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</li>
<li>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).</li>
</ul>
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.<br>
<br>
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<br>
<br>
This is not on master yet, I hope it'll find its way here after the
bootstrap.<br>
<br>
Mildred<br>
<tt></tt>
<pre class="moz-signature" cols="72"><tt>--
Mildred Ki'Lya
╭───────── ｍｉｌｄｒｅｄ５９３＠ｏｎｌｉｎｅ．ｆｒ ──────────
│ Jabber, GoogleTalk: <a class="moz-txt-link-rfc2396E" href="mailto:mildred@jabber.fr"><mildred@jabber.fr></a>
│ Website: <a class="moz-txt-link-rfc2396E" href="http://ki.lya.online.fr"><http://ki.lya.online.fr></a> GPG ID: 9A7D 2E2B
│ Fingerprint: 197C A7E6 645B 4299 6D37 684B 6F9D A8D6 9A7D 2E2B
</tt></pre>
</body>
</html>