Discussion :

[Roland Chastain]

Bonjour !

N'y aurait-il pas un moyen d'automatiser la reconstruction de l'EDI en fonction d'une liste de composants donnée ? Ou, à défaut, y a-t-il un moyen d'installer plusieurs composants à la fois et de reconstruire une seule fois ?

[BeanzMaster]

N'y aurait-il pas un moyen d'automatiser la reconstruction de l'EDI en fonction d'une liste de composants donnée ? Ou, à défaut, y a-t-il un moyen d'installer plusieurs composants à la fois et de reconstruire une seule fois ?

Peut être en passant pas un script BATCH comme l'installation de CodeTyphon

[Jipété]

Salut,

N'y aurait-il pas un moyen d'automatiser la reconstruction de l'EDI en fonction d'une liste de composants donnée ? Ou, à défaut, y a-t-il un moyen d'installer plusieurs composants à la fois et de reconstruire une seule fois ?

C'est à moi que tu poses ces questions ? Alors la réponse est : je n'en sais absolument rien !

Ceci étant dit, automatiser la reconstruction de l'EDI en fonction d'une liste me semble bizarre, tout comme installer plusieurs composants à la fois, qui ne ressemble pas à la vraie vie.

Dans la vraie vie, on installe un composant par ci par là de temps en temps, et vient le moment où il faut faire la mise à jour de l'environnement de dev, qui consiste, la plupart du temps, en une tripotée de fichiers plus ou moins modifiés, et qui nous oblige à tout supprimer pour tout réinstaller : complètement stupide !

Je reste persuadé, sans aller jusqu'aux procédures de patch des fichiers eux-mêmes (quoique... Linux sait le faire pour par exemple les fichiers source du noyau [et Dieu sait qu'il y en a !]), qu'il suffirait de juste remplacer les fichiers version n par les fichiers version n+1 puis de recompiler pour avoir un environnement à jour.

Ok, cette procédure ne mettrait pas à jour les composants rajoutés par l'utilisateur, dans le cas où une màj serait dispo pour eux, mais c'est un autre problème (qui pourrait se résoudre de la même manière, d'ailleurs).

[alanglet]

Bonsoir,

N'y aurait-il pas un moyen d'automatiser la reconstruction de l'EDI en fonction d'une liste de composants donnée ? Ou, à défaut, y a-t-il un moyen d'installer plusieurs composants à la fois et de reconstruire une seule fois ?

C'est bien comme çà se passe si vous faites la mise à jour des sources par SVN au lieu de réinstaller Lazarus.
Je le fais avec la version en développement (trunk) mais comme vous êtes très prudent je pense que vous pourriez le faire avec la version en cours. Il faut sans doute choisir la bonne branche sur le dépôt SVN.
Tortoise SVN met à jour les sources. Il n'y a plus ensuite qu'à "Créer Lazarus avec le profil Clean up + Build all"
Tous les composants installés, même les vôtres sont alors recompilés.
Les quelques problèmes que j'ai pu rencontrer en faisant ainsi étaient dus à des composants à adapter aux évolutions ou à des composants que leur auteur présente comme "un atelier", bourrés de références circulaires, qui devaient être compilés plusieurs fois (composants que j'ai préféré supprimer tant ils étaient mal conçus).

André

[Jipété]

Yop !

Ah ah ! Une piste intéressante !

Bonsoir,

C'est bien comme çà se passe si vous faites la mise à jour des sources par SVN au lieu de réinstaller Lazarus.
Je le fais avec la version en développement (trunk) mais comme vous êtes très prudent je pense que vous pourriez le faire avec la version en cours. Il faut sans doute choisir la bonne branche sur le dépôt SVN.
Tortoise SVN met à jour les sources. Il n'y a plus ensuite qu'à "Créer Lazarus avec le profil Clean up + Build all"
Tous les composants installés, même les vôtres sont alors recompilés.
Les quelques problèmes que j'ai pu rencontrer en faisant ainsi étaient dus à des composants à adapter aux évolutions ou à des composants que leur auteur présente comme "un atelier", bourrés de références circulaires, qui devaient être compilés plusieurs fois (composants que j'ai préféré supprimer tant ils étaient mal conçus).

André

Je mets ici un lien vers la doc officielle du truc, et en français s'il vous plait !
Mais il va y avoir beaucoup de lectures, je sens (par exemple le lien en français ci-dessus est moins complet que l'officiel, mais il a des scripts en plus...), et pas mal de questions, et d'essais...

Bon, je vais d'abord me créer une machine virtuelle dédiée à ça. À suivre...

[alanglet]

Au départ j'ai installé sous Windows en suivant la méthode décrite aussi dans le wiki ici qui permet également la mise à jour de FPC. Les liens sont évidemment à adapter avec les versions actuelles.
Le téléchargement et la mise à jour des sources se fait avec TortoiseSVN. Après l'exécution d'un fichier .bat pour compiler FPC (c'est le plus long), il n'y a plus qu'à recompiler Lazarus depuis le menu Outils, sauf la toute première fois où il doit construit depuis un fichier .bat.

André

[Jipété]

Bonjour,

avant d'aller plus loin, j'aimerais bien une (toute petite) explication à propos de tags, branches, trunk, etc.

Parce que je m'y perds...

Supposons que je veuille installer dans une machine vierge non pas la toute dernière version, mais une version un peu antérieure de fpc et de lazarus, pour ensuite tester les mises à jour. Comment dois-je m'y prendre ?

Merci pour le retour,

[alanglet]

Bonjour,

Je ne sais si je peux vraiment t'aider car je n'utilise que la version sous Windows, et si j'ai bien compris tu travailles sous Linux.
Comme déjà dit j'utilise TortoiseSVN, interface graphique de SVN qui facilite bien les choses en s'intégrant dans l'explorateur. On peut trouver un mode d'emploi ici . On y trouve aussi des explications concernant SVN en mode console.
Une fois Tortoise ou un autre client SVN installé, il faut créer sur le PC le répertoire où tu veux installer les sources. A l'aide du client SVN il faut alors "extraire" les fichiers du dépôt SVN. Apparemment le dépôt des dernières sources officielles de Lazarus est à l'adresse http://svn.freepascal.org/svn/lazaru.../lazarus_1_4_4
Il est possible d'extraire les sources à la dernière révision (Head) ou à une précédente à définir.
Espérant que cela t'aidera...

André

[alanglet]

Une autre vue pour montrer l'arborescence de mon installation de FPC/Lazarus.
Tout est dans le répertoire d:\freepascal.
N'utilisant que les sources issues du "trunk" ne pas tenir compte des répertoires binutils et fpc\2.6
Il est préférable de ne pas mélanger plusieurs "extractions de sources" dans le même répertoire. Je veux dire par là que le répertoire de FPC ne doit pas être un sous répertoire de Lazarus comme cela est fait dans l'installation standard.
Le dépôt de FPC est ici dans d:\freepascal\fpc\trunk et Lazarus dans d:\freepascal\laz.
Les composants personnels ou ajoutés depuis d'autres dépôts sont dans d:\freepascal\composants et non dans d:\freepascal\laz\components. Les compléments lazarus-ccr issus du dépôt https://svn.code.sf.net/p/lazarus-ccr/svn ont aussi droit à leur répertoire séparé.

André

[Jipété]

Hello,

Je ne sais si je peux vraiment t'aider car je n'utilise que la version sous Windows, et si j'ai bien compris tu travailles sous Linux.

Ben c'est surtout que tu n'as pas répondu à la question toute simple qui me turlupine et que je repose :

avant d'aller plus loin, j'aimerais bien une (toute petite) explication à propos de tags, branches, trunk, etc.

Parce que je m'y perds...

Supposons que je veuille installer dans une machine vierge non pas la toute dernière version, mais une version un peu antérieure de fpc et de lazarus, pour ensuite tester les mises à jour. Comment dois-je m'y prendre ?

Parce que sinon, Windows, Linux, pour moi c'est un peu pareil :-)
Mais je ne veux pas me mélanger les pinceaux avec ces tags, branches, et autres trunks : je ne sais pas quelle option choisir...

Il est préférable de ne pas mélanger plusieurs "extractions de sources" dans le même répertoire. Je veux dire par là que le répertoire de FPC ne doit pas être un sous répertoire de Lazarus comme cela est fait dans l'installation standard.

Complètement séparés sous Linux, donc pas de souci de ce côté-là.

Je prends bonne note, cependant, de ce réglage que je trouve sympathique :

Les composants personnels ou ajoutés depuis d'autres dépôts sont dans d:\freepascal\composants et non dans d:\freepascal\laz\components.

Je l'adopterai certainement si je vois le bout du tunnel du merdier dans lequel je suis tombé en fin de création de Lazarus...

J'ai découvert un outil qui a l'air sympathique, fpcup, pour gérer le client subversion et lancer téléchargements, compilations, installations, etc., à condition de bien capter les réglages des fichiers ini (oui, il y en a 2 !), et j'ai passé la journée dessus, avec un gros sentiment de désespoir et de temps perdu parce que si tout s'est à peu près bien passé, la compilation et l'édition des liens du binaire Lazarus se solde par un échec cuisant avec un message plus que sibyllin : Can't call the linker, switching to external linking

Alors bien sûr j'ai farfouillé partout dans la machine (virtuelle, je vous rassure), j'ai même trouvé des vieux fichiers de config (alors que ce matin j'avais proprement désinstallé fpc, fpcsrc et lazarus, à croire que Linux c'est aussi merdique que Windows), mais rien qui me dise qu'est ce que c'est que ce linker, comment s'appelle-t-il, où faut-il le chercher...
La seule piste que j'ai c'est que l'erreur est remontée comme étant située dans le fichier install_laz/ide/lazbuild.lpr, à la ligne 1672 : j'y fonce et qu'est-ce que j'y trouve ? end., c'est la dernière ligne du fichier.

C'est donc très simple : si je ne passe pas ce mur, le bazar SVN pour moi c'est mort.

Allez, j'y retourne...

[alanglet]

avant d'aller plus loin, j'aimerais bien une (toute petite) explication à propos de tags, branches, trunk, etc.

Difficile de te répondre avec précision, parce que les développeurs ont une assez grande liberté pour organiser leur dépôt. Il y a surtout des "traditions"...
En général dans trunk on trouve les dernières évolutions d'un projet. Dans branches et tags, les développeurs peuvent copier trunk ou une autre branche à une certaine révision pour y faire des essais ou pour figer dans un état déterminé. Il y a même des dépôts où on peut trouver des projets différents dans les branches. Il faudrait demander ou chercher sur le forum de Lazarus les règles que ce sont imposées les développeurs. Tu peux aussi explorer le dépôt avec le navigateur et consulter le journal des évolutions (à condition que les développeurs n'y soient pas trop succincts) pour savoir à quel stade est une branche.
Comme dit précédemment, il me semble que c'est la branche lazarus_1_4_4 qui devrait t'intéresser.

André

[Jipété]

Merci pour les précisions, je vais aller fouiller...

Comme dit précédemment, il me semble que c'est la branche lazarus_1_4_4 qui devrait t'intéresser.

Ben non, ce qui m'intéresse c'est d'installer plutôt la 1.4.0 et vérifier qu'elle s'installe et que ça fonctionne (ce qui n'est pas le cas à l'heure actuelle), et ensuite tester une migration 1.4.0 --> 1.4.2 et vérifier que les composants que j'aurais installés dans la 1.4.0 seront toujours présents, puis faire d'autres bidouilles et enfin upgrader en 1.4.4.
Et si là ça fonctionne encore, alors je pourrai dire que ce système est envisageable.

Mais pour le moment j'en suis loin car, si j'ai réussi à installer un mini IDE en suivant les instructions trouvées dans le README à la racine du dossier Lazarus puis ensuite le big IDE (mais dans les deux cas j'ai des problèmes de chemins qui font que ces 2 IDE's ne sont pas opérationnels), en tout état de cause, malgré des heures et des heures sur le web, ça ne fonctionne pas avec l'outil fpcup, prévu pour ça.
J'ai du pain sur la planche de ce côté-là...

[alanglet]

Bonjour,

Je n'ai pas essayé avec d'autres méthodes que celle dont j'ai donné le lien (mot "ici" dans mon message d'hier à 00h05). Mais je peux te dire qu'avec celle-là ça marche puisque je mets mon installation régulièrement à jour. Le seul problème récurent c'est lors de la compilation de FPC; la compilation s'arrête parce que le répertoire units n'est pas correctement nettoyé. Il suffit de le supprimer manuellement ou d'inclure ce nettoyage dans le .bat.
Une différence cependant avec ce que semble-t-il tu es en train de faire. Je fais les mises à jour depuis toujours le même dépôt "trunk". Si j'ai bien compris, tu veux d'abord télécharger depuis un dépôt 1.4.0 puis ensuite mettre à jour avec un autre dépôt 1.4.2. etc...
Je doute que cela fonctionne, du moins pas aussi simplement qu'avec les commandes "SVN mettre à jour" ou "Mettre à jour à la révision..." depuis toujours le même dépôt. Mais je ne connais pas suffisamment SVN pour te dire si une commande le permet.
A ta place (mais je ne le suis pas) et si ton but est de tester l'évolution d'une version à une autre, avec le navigateur de dépôt je commencerai par identifier à quelles révisions correspondent chacune des versions que tu veux tester.
V1.4 -->R48774
V1.4.2 -->R49524
V1.4.4 -->R49931
tirées de la liste figurant dans le répertoire tags en supposant que dans ce répertoire figurent bien des versions figées et non des branches de tests.
Puis je ferai la première extraction depuis trunk à la révision 48774. Lors des mises à jour suivantes je préciserai la version voulue supérieure etc... sans changer de dépôt.

André

[Jipété]

Yop !

"trunk", d'après ce que j'en lis là

If the current trunk version is in a state of rapid change and unsuitable for much use unless you want to work on the compiler itself, you can stay on a version that is updated with fixes. To do this, you have to find out a stable branch that you want to track instead of the default trunk development version.

, vaudrait mieux pas y toucher. Après, chacun fait comme il le sent, hein

Bon, j'ai une piste, mais j'ai encore pas mal de boulot, je vous tiens au courant...

[Jipété]

Bon, j'ai une piste, mais j'ai encore pas mal de boulot, je vous tiens au courant...

Ma piste était bonne, après de nombreux et laborieux essais (et à chaque fois c'est 15 à 20 minutes d'attente, entre le téléchargement et les compilations),plus des blagues de l'interface GUI (à ne surtout pas utiliser ! C'est une catastrophe...) : j'ai d'abord fait installer et compiler un fpc 2.6.0, que j'ai pu upgrader en 2.6.2 puis 2.6.4 tip-top, le seul souci mais il est de taille c'est que contrairement à l'option dont le nom et le commentaire avaient l'air sympathique :

Code ini :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
; In case you want to submit patches, it's nice to be able to update
; without overwriting your fixes:
keeplocalchanges=true

je me suis amusé à changer un fichier sur lequel on avait travaillé il y aura bientôt deux ans, et les modifications sont perdues à chaque changement de version.
C'est très nul, ça, je trouve.
Alors c'est peut-être moi qui utilise mal l'outil, mais je n'ai pas trouvé d'autre option...

Ça, c'était pour fpc.
Pour Lazarus, c'est la même catastrophe qu'hier : tout se passe bien pendant 10 minutes puis, lors de la compilation de Lazbuild, paf !, rateau.
Avec le même message d'erreur qu'hier, tellement nul que je ne sais absolument pas où chercher :

Code text :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
...
(9022) Compiling resource ../units/i386-linux/nogui/lazbuild.or
 [2015-10-26 18:34:04.367 Info] (9015) Linking ../lazbuild
/usr/bin/ld: warning: ../link.res contains output sections; did you forget -T?
 [2015-10-26 18:36:23.495 Info] /opt/devel/pascal/laz/ide/lazbuild.lpr(1672,1) Error: (9014) Can't call the linker, switching to external linking
/opt/devel/pascal/laz/ide/lazbuild.lpr(1672,1) Fatal: (10026) There were 1 errors compiling module, stopping
Fatal: (1018) Compilation aborted

Ça doit être un problème de chemin, ou de raccourci, ou qqchse de ce style-là, parce qu'il suffit d'aller dans le dossier laz avec une console et de taper make et quelques minutes après on a un Lazarus parfaitement fonctionnel, la preuve :



Si mon client svn ne fait pas correctement son boulot, c'est la cata...
Un peu dégoûté, ce soir, après deux jours pleins là-dessus et pas de direction pour chercher une bonne idée...

[Jipété]

Des nouvelles :

Pour Lazarus, c'est la même catastrophe qu'hier : tout se passe bien pendant 10 minutes puis, lors de la compilation de Lazbuild, paf !, rateau.
Avec le même message d'erreur qu'hier, tellement nul que je ne sais absolument pas où chercher :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
...
 [2015-10-26 18:36:23.495 Info] /opt/devel/pascal/laz/ide/lazbuild.lpr(1672,1) Error: (9014) Can't call the linker, switching to external linking

Ça doit être un problème de chemin, ou de raccourci, ou qqchse de ce style-là, parce qu'il suffit d'aller dans le dossier laz avec une console et de taper make et quelques minutes après on a un Lazarus parfaitement fonctionnel

Ben non, c'était pas un problème de chemins : après avoir blindé le code de fpcup de writeln pour m'en dire plus et en avoir rajouté aussi dans le link.pas de fpc, j'ai pu avoir la satisfaction de constater que ce problème était lié à une absence de mémoire !
Vous parlez d'un message d'erreur pas explicite du tout
'fin bon, j'ai déclaré 2 Go à la machine virtuelle (au lieu de 1) et tout va bien maintenant de ce côté-là.

Du côté des patches, je considère que ce sont des choses à gérer à la main, trop dangereux d'automatiser ça, et pour les composants installés, il semblerait que l'outil fpcup soit capable de les gérer...
Plus d'infos quand ça sera testé.

Mais déjà, j'ai un meilleur moral qu'il y a 24 heures
Allez, j'y retourne, il y a encore plein de manips à faire avant de déclarer ça fonctionnel...

[Jipété]

Yop !

De nouvelles nouvelles

Non, je ne suis pas tombé dans une faille spatio-temporelle, juste dans un truc tellement mal foutu que ça y ressemblait, et pendant un moment j'ai bien cru ne plus en sortir, mais la chance sourit aux audacieux, malgré des galères effroyables racontées dans le sous-forum voisin.

Bref, je crois que j'ai progressé dans la compréhension de ce machin qui gère les fichiers .ini d'une manière plus que farfelue : d'abord il y en a deux, en plus, selon la section qu'on appelle (oui, on n'a droit qu'à une seule section, truc de ouf' !) et ce qu'on veut faire (la misère a été l'installation des composants : deux jours dessus...) il y a besoin d'autres sections que le programme appelle mais il y a intérêt à utiliser les noms pré-définis codés en dur dans l'appli (nul !) parce que sinon ça fait très mal, heureusement que j'avais le code source (écrit en Lazarus ) pour m'y retrouver.
Je vous passe les informations périmées dans les fichiers .ini ou dans les .pas (600 ko de lignes de code réparties dans 40 fichiers), ça aussi ça fait mal...

D'autres nouvelles demain, car là j'ai juste fait une simulation d'installation de deux composants, pour voir si je m'en sortais du flooding de la console par des messages d'erreur et, oui, ça y est.
Demain la vraie vie !

[Jipété]

D'autres nouvelles demain, car là j'ai juste fait une simulation d'installation de deux composants, pour voir si je m'en sortais du flooding de la console par des messages d'erreur et, oui, ça y est.
Demain la vraie vie !

Alors dans la vraie vie, le nouvel outil (enfin, depuis quelques années maintenant) de gestion du système sous Linux, j'ai nommé la cochonnerie systemd m'aura fait perdre la moitié de la journée mais l'autre moitié aura été assez positive, on va dire.

Bien sûr il aura fallu créer avant la liste qui va bien dans un fichier ini, mettre tous les paquets dézippés dans un dossier "maître", se prendre pas mal la tête avec la structure de ce fichier ini mais à la fin, on gagne ça (8 composants à installer) en une seule commande (tout le monde aura reconnu le bout droit du bandeau supérieur de l'IDE) :



Je pense que ça sera très utile lors des prochaines mises à jour...

[Jipété]

3 jours plus tard...


Légende de l'image :

• en bleu les dossiers,
• en vert les fichiers exécutables (binaire, script)
• en blanc les fichiers texte.

J'ai donc créé dans /opt un dossier "devel" dans lequel j'ai créé un sous-dossier "pascal", dans lequel j'ai créé trois sous-dossiers : "composants", "fpcup", et "patches". Les autres seront créés automatiquement.

"composants" et "patches" comme les noms l'indiquent, ne nécessitent pas d'explications, sauf une, pour les patches, qu'il faut passer à la main : je préfère cette méthode qui permet de vérifier que le patch qu'on va appliquer correspond bien à un fichier qui en a besoin (des fois qu'il ait été mis à jour).
Pour l'heure ça ne concerne (pour moi) que fpreadtiff.pas dans fpc (dont on a parlé ici il y a un an ou deux), et easylazfreetype.pas pour laz, qui sera probablement mis à jour un jour, d'où le contrôle à la mano !

La grosse partie du boulot se trouve dans le dossier "fpcup" dans lequel on trouve :

• un binaire recompilé par mes soins suite à microscopiques modifications dans les sources, mais ça m'a bien aidé ;
• un fichier fpcup.ini n'est n'est pas celui d'origine (que vous sauvegarderez dans un coin, on ne sait jamais) et qui m'a fait souffrir le martyre parce que c'est très mal expliqué et même parfois carrément périmé...
• un autre fichier d'intialisation "settings.ini" que je n'ai pas eu le courage d'enlever (on ne sait jamais...) mais que je n'ai pas modifié ;
• et enfin le script "start_fpcup.sh" qui fait le boulot, créé par mes soins et commenté, parce que l'articulation de tout ça est un peu casse-gueule.

Mais ça m'aura quand même permis de, dans l'ordre :

1. installer fpc 2.6.0 et laz 1.4.0
2. upgrader fpc vers 2.6.2
3. upgrader fpc vers 2.6.4
4. installer les composants dans laz
5. upgrader laz vers 1.4.2
6. upgrader laz vers 1.4.4

et tout ça en ne faisant qu'une modif (ou deux) à la fois dans le .ini, et une ou même pas dans le script, en fonction de la cible.
Deux exemples pour illustrer l'idée : upgrader une version se définit dans l'ini, installer les composants de laz plutôt que l'ide se définit dans le script.

Le seul souci qui reste c'est cette perte du paramètre de langage dans l'IDE de laz après un upgrade... Je ne renonce pas à l'idée de rajouter une ligne ou deux dans le script pour remettre ça d'équerre :-)

La modif dans les sources de fpcup (c'est bien, c'est écrit en Lazarus ) :
on trouve, dans le fichier fpcup.lpr, à quatre endroits différents, la ligne writeln('Error : wrong command line options given:'); , ce qui, vous en conviendrez, n'est pas pratique pour savoir ce qui a fait planter et où.
J'ai donc modifié ces lignes en rajoutant simplement (1) à (4) après le mot "error" et je vous engage à faire de même, ce me fut trop utile ! (lignes 526, 545, 614 et 656).

Voilà.
Il ne me reste plus qu'à mettre tout ça en prod dans la vraie vie, ce qui va consister d'abord à supprimer les installations de fpc, fpcsrc et lazarus sur la machine physique, sacrilège !, pour ensuite court-circuiter l'outil d'installation des paquets (autre sacrilège, ) et ça devrait le faire.

Le seul problème que j'ai rencontré, c'est lors du patch du fichier fpreadtiff.pas : je m'étais noté dans un coin qu'après avoir modifié le fichier il suffisait de taper "make" et ça compilait de nouveaux .o et .ppu mais avec cette nouvelle installation, terminée la simplicité !
J'ai passé environ deux heures pour trouver toutes les options à rajouter à fpc (oui, au passage j'ai changé de compilo, la structure et les paramètres d'un Makefile me faisant trop pleurer), je m'en suis sorti mais je crains le pire s'il faut un jour patcher plusieurs fichiers qui se mordent la queue.
On verra bien.

En pj un zip contenant le fichier ini (plein de commentaires, c'est un peu brut de décoffrage, enfin, ça vous donnera une idée de ce que j'ai vécu ) et le script, commenté également : tools.zip

EDIT : y aura qu'à rajouter ça à la fin du script (non testé en vrai, mais en simulation c'est bon), et ça devrait régler ce problème de langue :

Code bash :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
checklaz=${inisection/laz} # enlève 'laz' dans inisection et met le résultat dans checklaz
# les chaines seront différentes s'il y avait 'laz' dans 'inisection'
if [ "$checklaz" != "$inisection" ]; then 
	configfile=$installdir/config_laz/environmentoptions.xml
	# bien penser à "échapper" les caractères interprétables : 2e et 3e doubles quotes qui font croire 
	# qu'on termine une chaîne avant d'en ouvrir une autre, et le caractère anti-slash qui indique 
	# un retour à la ligne...
	str1="<Language ID=\"en\"\/>"
	str2="<Language ID=\"fr\"\/>"
	sed -i "s|${str1}|${str2}|" $configfile
fi

librement inspiré de # http://www.developpez.net/forums/d15...tring-fichier/

[BeanzMaster]

Salut he ben ! tant as eu du courage tu crois que cela serai applicable sous Windows ? si juste par hasard je viens de tomber la dessus http://wiki.freepascal.org/LazSVNPkg
Je vais y jeter un oeil cela à l'air très intéressant
A+