Open source software, veel van de lezers gebruiken het al in meer of mindere mate. Misschien niet altijd bewust, maar het zit al op zoveel plaatsen verweven dat we er haast niet meer om heen kunnen. Het is echter ook zo dat de meesten niet echt de sources gebruiken, maar reeds gebouwde producten, gebaseerd op open source code. Op het moment dat je met de broncode aan de slag gaat kun je voor een paar leuke uitdagingen komen te staan.
Onlangs kreeg ik de vraag om eens te kijken of ik één van de open source pakketten die we gebruiken ook zelf gebouwd kon krijgen, dit in verband met lange-termijn onderhoudsverplichtingen (tot nu toe was er een reeds gebouwde versie in gebruik). Zo gezegd, zo gedaan … dacht ik.
Het downloaden van de source code was uiteraard het begin, en met behulp van internet was al snel gevonden hoe je zou moeten kunnen bouwen. Dit begon met het downloaden van een drietal ondersteunende producten. Na het nodige gestoei om systeemvariabelen en paden goed te zetten lukte het zowaar om te bouwen. Uiteraard volgde daarop een test om te kijken of een en ander nog werkte, die al snel faalde op missende header files in het gebouwde product. Een zoektocht op internet leverde na verloop van tijd op dat er blijkbaar een regeltje ontbrak in de instructie die ik gevonden had.
Om een lang verhaal niet nog langer te maken: na zeven additionele tools/libraries geïnstalleerd te hebben was ik eindelijk in staat de binaries te reproduceren. Alhoewel… bij de gedownloade binaries stond nergens vermeld welke versies van de additionele tools/libraries gebruikt zijn bij het bouwen van die ene versie, dus of ik nu echt hetzelfde heb gereproduceerd is nog maar de vraag.
Voor het vervolgproject is al aangegeven dat men naar een nieuwere versie van betreffend open source product wil. Tijdens het zoeken naar de instructies voor de huidige versie bleek dat het bouwen van de nieuwe versie wezenlijk verschilt van de bestaande. Ik zie de bui dus al weer hangen.
De oudere jongeren onder ons, die eind jaren negentig al met Linux werkten, herkennen wellicht veel van dit verhaal. Destijds moest je ook, om één pakket aan de praat te krijgen, talloze andere pakketten downloaden en zelf configureren en bouwen. De hele exercitie leverde me dan ook een groot déjà-vu gevoel op. Nu, zo’n vijftien jaar later is Linux veel volwassener geworden, en neemt het package management systeem je nagenoeg al het werk uit handen.
Hopelijk krijgen we op termijn voor het zelf bouwen van open source iets vergelijkbaars.
@Benno: voor een gecontroleerde omgeving zoals een kantoor is dat makkelijker te realiseren dan voor een open source community waar de ontwikkelaars thuis zitten te werken.
In mijn dagelijkse omgeving hebben de ontwikkelaars gedefinieerde installaties, en zijn de bouw- en testmachines op dezelfde manier ingericht. Hiermee voorkomen we veel problemen, maar het kan nog altijd voorkomen dat een ontwikkelaar lokaal iets anders heeft gezet waardoor het op de bouwomgeving alsnog misgaat. In dat geval zijn de afspraken heel helder: de bouwomgeving is leidend.
@Jan: voornamelijk omdat we in de afdeling waar ik werk alles op windows doen. Ik zou het misschien ook wel aan de praat krijgen in een (al dan niet virtuele) linux omgeving, maar iemand moet die omgeving ook nog kunnen managengebruiken als ik er niet ben.
Vanwege lange onderhoudsverplichtingen is het streven zo min mogelijk uitzonderingen op de standaard te hebben.
Ya pa, the goodold dependency en reproduce hell.
yum/yast over rpm, apt over dpkg voor linux binaries ?
freebsdports en wellicht gentoo voor bsd/linux sources ?
Misschien moeten we Cloud fluisteraar Henri volgen, opensource kan steeds vaker ook van de plank. hahaha, Henri volgen. Wat zeggik nu ? Vooruit dan maar. Mooi weer en bijna weekend. wtf.
@pa va ke;
zijn er spec files of source rpms beschikbaar? dan kun je yum gebruiken om aan al je build dependancies te voldoen. Voor oeloeboentoe en afgeleiden kun je apt-get gebruiken om de source package binnen te halen en de build te doen en alle dependancies op te lossen. Dat is vaak een makkelijker startpunt om daarna zelf een package te maken met de nieuwere versie van de software en te maintainen.
Het artikel lijkt mij te gaan over ontwikkelaars die niet bij blijven met de ontwikkelingen en daardoor in het verleden blijven hangen.
Ga anders maar eens een .net 2.0 applicatie porten naar .net 4.x en je komt soortgelijk ‘gedoe’ tegen met afhankelijke libraries. En zul je e.a. aan moeten passen ivm veranderde api’s.
Dat er nog meer geautomatiseerd kan worden in deze tak van de ontwikkelsoftware staat als een paal boven water. Maar blijkbaar is op dat vlak de innovatie niet zo noodzakelijk om de mensen zich goed kunnen redden met wat ze hebben.
Felix, RedHat (of een derivaat ervan) is op zich een prima keuze voor de enterprise markt.
Maar first of all, het is niet de enige keuze en ook niet speciaal de keuze voor developers.
Ik denk dat is het voorbeeld van Pascal (van Kempen that is) het wel handig zou zijn als de documentatie (if any) zou verwijzen naar de vanila versies van de mee te linken libs.
Maar al te vaak roepen developers dat ze geen gepatchte versies ondersteunen (Ubuntu, Debian, RedHat, SuSe allemaal halen ze die ongein uit)
Overigens Pascal, een opmerking van je valt me tegen.
Je onderbouwing voor het porten naar Windows zie ik in essentie als onvermogen om gekwalificeerde colega’s te vinden (op zich weer een bekend probleem)
Als dat werkelijk het probleem zat kun je beter alles in Java en DotNet bouwen en elke vorm van inovatie diep in een lade duwen.
Overigens dank voor je interesante opinie en de reacties hierop.
@spec: volgens mij heb je wat gemist in de reacties. Het gaat hier om een poging iets te bouwen op een windows omgeving, dus rpm en spec files gaan met niet helpen zover mijn kennis reikt
@Peter: ja en nee. Er zit een groot verschil in applicaties die je zelf ontwikkeld hebt, waar de kennis van in huis is en welke goed gedocumenteerd is of een brok software waarbij je afhankelijk bent van een community.
Overigens een gewaagde uitspraak over ontwikkelaars die je doet. De mensen waar ik mee werk zijn van een iets ander kaliber dan de uurtje-factuurtje codekloppers van bijv. een cap-gemini, neem dat maar van me aan.
@Pascal: er zijn natuurlijk meerdere wegen die naar Rome leiden hoe dit probleem te tackelen. Een linux omgeving opzetten en bijbehorende kennis inhuren/eigen maken is er één van. Ik heb in één van mijn vorige banen in een een hybride omgeving (linux/unix/windows) gewerkt, en ook dat brengt de nodige uitdagingen met zich mee als het gaat om portabiliteit / compatibiliteit. It’s all about choices.
Ik herken de problematiek zeker. Kennelijk val ik onder de oudere jongeren met een leeftijd van 40.
Zeker als je een halfdood pakket probeert te gebruiken, dat grotendeels op een bepaalde revisie is blijven steken, loop je tegen dit soort problematiek.
Probleem is de ‘wildgroei’. Was het vroeger FunctieXY(ArgumentA, ArgumentB) dan is het nu bijvoorbeeld FunctieXY(ArgumentA,ArgumentB,ArgumentC). Tijdens het compileren gaat dat natuurlijk helemaal mis en moet je terug gaan werken met de libraries totdat je dezelfde compileerbare functies weer hebt. Andere oplossing zou zijn uitzoeken wat ArgumentC doet en het overal in de broncode vervangen.
Aan het eind van je exercitie heb je wel het pakket draaiende gekregen, Pavake.. Bij closed sourced van een overleden leverancier kan je gewoon niets meer doen.
@pa va ke
yep, maar ook bij het nogmaals lezen van je eigen stukje, was mij dat ook niet geheel meteen duidelijk ;).
ken je mingw? http://www.mingw.org/ verder deel ik wel de menig van anderen; je bent met symptoom bestrijding bezig door zo iets op windows te willen doen waar het OS dus niet de meest logische keuze voor is omdat de tools op dat OS haaks op een unix filosofie staan.
Zelf heb ik me regelmatig vervloekt om een eenvoudige portable c++ code die op elk POSIX systeem dat er was (en DOS met borland destijds) zonder problemen compileerde en slechts een make file van 10 regels nodig had in de MS visual c++ IDE te krijgen. Mijn god hoeveel buttons en dialogen je door moest en extra .dlls toevoegen voordat er een .exe kwam. Toen ik eenmaal ook het knopje gevonden had wat de IDE onder de kap dan als commando uitvoerde, heb ik daar maar heel snel een .bat van gemaakt en nooit meer naar die IDE specifieke gekeken. Anderen zullen wel anders vinden.
@spec @pascal: de keuzes die gemaakt zijn, zijn voor een buitenstaander wellicht niet altijd logisch, maar in een streng gereguleerde omgeving waarin ik werk gelden soms andere criteria dan de meest logische.
Dit heeft alles te maken met het moeten valideren van ontwikkelomgevingen etc. alvorens wij producten op de markt mogen zetten. Overstappen naar andere compilers (mingw) of OSsen (Linux) heeft daardoor nogal wat voeten in aarde.
(het moeten installeren van allerlei “hulp-tools” om iets te kunnen bouwen is soms onontkoombaar, maar brengt dus soms ook het nodig extra werk met zich mee)