Construire les membres changés

du RSE.
Bien entendu, vous pouvez modifier
les membres changés au fil des besoins
et, en configurant votre style de
construction à  partir des propriétés du
projet, vous pouvez stopper le comportement
par défaut qui entraîne la
régénération de ce membre CL chaque
fois que vous sélectionnez l’action
Remote Actions, Build. Cette action
pousse vers la bibliothèque associée
du projet et le compile et l’exécute sur
l’iSeries.
De plus, si vous créez manuellement
un membre BIND.CLLE, lui aussi
sera poussé, compilé et exécuté sur un
build, mais seulement si le membre
COMPILE se compile et s’exécute correctement.
C’est là  que vous pouvez
mettre des actions de post-compilation
comme la liaison de vos modules ILE
dans des programmes et des programmes
de service. Tous les builds
soumis sont affichés dans un « iSeries
Build Job Status », où on peut facilement
surveiller leur état dans la file
d’attente des jobs.
Au terme de l’opération, toutes les
erreurs provenant de toutes les compilations
sont combinées et vous pouvez
les afficher dans une vue Error List
unique en faisant un clic droit sur l’action
Retrieve Errors dans la vue Build
Status. Comme dans le RSE, quand
vous double-cliquez sur l’une de ces
erreurs, le membre est ouvert dans
l’éditeur et vous vous trouvez juste sur
l’erreur. Bien entendu, si vous avez utilisé
des vérificateurs, vous n’aurez plus
jamais d’erreurs de compilation dans
vos membres RPG, Cobol ou DDS. La
figure 4 montre les vues Build Job
Status et Errors List.
On nous demande souvent d’affecter
de façon permanente la liste des bibliothèques
d’un projet afin que les
builds choisissent les bibliothèques
nécessaires. La réponse est la même
que dans le cas du RSE : utiliser l’action
Properties sur la connexion associée,
dans la vue Remote Systems, dans la
page Subsystems, iSeries Commands.
Il existe d’autres options pour les
builds, appelées build styles. Par
exemple, il existe un build style pour
simplement exécuter une commande
iSeries que vous indiquez dans la configuration
du build style. C’est le bon
choix si vous avez déjà  un processus
pour construire votre application. Si
vous utilisez sur l’iSeries certains produits
classiques de gestion du changement,
il est probable qu’ils fournissent
leurs propres build styles, lesquels s’intègrent
dans la perspective iSeries
Project. L’action build est conçue spécialement
pour que les fournisseurs
puissent l’étendre et la développer, ce
qu’ils ont fait.