Bygge på flera maskiner med dependencies

[sirGustav]

Jag vill ha ett byggsystem som man skal gå från fräsch kod från repository till nybyggd installation med ett knapptryck och har funderat på hur man bäst skall representera ett sådant system. Problemet dyker upp då man kan lägga externa bibliotek och installera program var som helst.
Den bästa lösningen jag kan komma på är ett litet verktyg som kan lagra miljövariabler och köra igång bygge och editors med dessa aktiva, ungefär såsom det vi har på jobbet fast mycket enklare. Det är ett enkelt program och kommer nog inte ta mer än en helg, så om det inte finns några bättre alternativ så kommer jag göra det

Hur hanterar ni det?

[dooz]

Miljövariabler som pekar ut koden för alla libbar som du ska kompilera med är vettigt, tror jag. Då slipper du i alla fall problem med att du har utvecklingsdirectories på olika drivar och sånt. Så har jag i mina grejer hemma, och det funkar bra att flytta projekt mellan datorer.

Sen är det problemet med externa libbar, som man egentligen inte vill bygga om, utan istället frysa till en viss version. Grejer som lua eller gtest. Sånt som man förmodligen kommer att bygga på varje maskin, fast inte har versionshanterat själv, utan tankar ner och bygger på varje ställe man är på. Äh, då är env. variabler bra också

Jag har försökt att göra någon vettig bundle någon gång, där jag kompilerar alla externa libbar på en burk, och sen skapar jag en libs-och-inc dir där jag dunkar ner alla 3e parts grejer (och in med det i mercurial), men jag orkade aldrig underhålla den, så får man ett beroende till ett nytt lib som man inte lägger in, och då har man två olika metoder, och då brakar allting samman..

[Hildenborg]

På Autodesk (eller snarare Opticore, som blev uppköpta), så hade dom systemet att starta Visual Studio med en batch fil för varje projekt.
I den batch filen, så satte man miljövariabler och lade till sökvägar till path'en. Miljövariablerna användes sedan i projektet, för att hitta libbar etc.

Det fanns ett irritationsmoment med att batch filen öppnade ett command line fönster, som stannade kvar på desktopen, men i det stora hela, så var man ändå nöjd med alla problemen det löste.

När vi fick ta över ett stort projekt från andra sidan atlanten, som inte var skrivet i visual studio, och berodde på en massa olika beroenden av installerade program och libbar, så skrev jag ett python skript som gick igenom alla källkoder och analyserade de installerade programmen. Och sedan byggde skriptet upp ett visual studio projekt med tillhörande batch fil, som satte alla unika miljövariabler etc. för just den datorn.
Efter det, så började folk kunna utveckla på sina datorer utan att det blev några problem med beroenden etc.

Det var ganska lätt att reverse-enginera ett visual studio makefile projekt.