[Tsp-devel] TSP 0.7.3

[Erk]

>De: Frederik Deweerdt [mailto:address@hidden
>Date: ven. 17/03/2006 17:00

>On 3/17/06, address@hidden <address@hidden> wrote:
>> Au passage j'aimerais créer la branche br_TSP_0_7_x pour
>> les modifs du multi-type tranquillement sur le trunk.
>>
>> Je ferais donc ça sauf si j'ai des avis contraire d'ici là.
>>

>Est-ce qu'on peut envisager d'intégrer un système de build SCons pour la 0.7.4?
Je suis POUR mais je ne pense pas avoir le temps de le faire
moi-même pour l'instant.
Je veux bien tester en revanche.

A priori la version après la 0.7.3 serait plutôt 0.8.0 vu les changements
qu'auront apporté le support des types multiples.

Une 0.7.4 viendra seulement pour ceux qui veulent des corrections 0.7.x
d'où la branche br_TSP_0_7_x.

C'est du chipotage mais ce serait donc plutôt pour la 0.8.0

>Comme les Makefile et SCons sont orthogonaux, on pourrait conserver
>les Makefile un moment avant de les retirer (ou ils disparaitront au fur et
>a mesure si ils ne sont plus maintenus).

Je suis 100% d'accord avec ça.
Le résultat pourrait aussi être que SCons ne fais pas l'affaire
et que les Makefile restent... mais je suis assez optimiste sur l'issue.

>D'autre part, doit-on conserver l'arborescence exec/ comme destination
>de binaires ou peut-on garder les .o + binaires dans src et ne les
>déployer que lors d'un scons install?

[Je trouve que] C'est toujours un peu cochon d'avoir des sources et des .o
mélangés joyeusement. Et l'avantage de l'architecture avec

exec/<version>/<arch>/bin
                                /lib
...

C'est que ça permet avec un seul coup de make/SCons de builder
pour plusieurs target (Host linux et Target VxWorks)
ou bien host Linux Intel et target Linux PPC.

On peut aussi en 1 passe compiler en debug ou opt.

C'est pour ça que nos Makefile sont ré-entrants et que le
fichier make/Makebuild.list est généré.

Idéalement de la même façon qu'on peut faire:

make TSP_TARGET=linux TSP_MODE=debug

on devrait pouvoir faire

SCons TSP_TARGET=linux TSP_MODE=debug

Toutefois je ferais une modif qui serait de renommer le répertoire
"exec" en "build" ce qui correspond mieux à son utilisation actuelle.

>Ca permettrait, dans une
>premiere version de build SCons, un dev plus simple.

Pourquoi plus simple?
Enfin je vois bien pourquoi c'est plus simple mais
c'est aussi bien pratique de générer les exécutables et les libs
dans des répertoires à part.

Ce qui est pénible en revanche avec l'histoire des .o à part
c'est que on ne doit pas avoir 2 fichiers qui portent le même nom
dans toute l'arvbi sous peine que

src/provider/bb_provider/init.o
soit pris pour
src/consumer/ascii_writer/init.o

Une solution qui me paraitrait à la fois simple et élégante
serait que l'arbo des sources soit recrée automatiquement par SCons
sous
$TSP_BASE/build/

donc le résultat de la compilation de
$TSP_BASE/src/consumer/tspfs/tspfs.c
finirait dans
$TSP_BASE/build/consumer/tspfs/tspfs.o

On peut oublier le prefixe <version>/<arch> pour l'instant
mais ce serait [je pense] facile à rajouter.


--
Erk