Post by Martijn van BuulPost by Philip PaepsJe trekt het weer in het extreme. De keuze van editor staat volledig los
van de keuze van "build system".
Dat is maar gedeeltelijk waar - de keuze van de editor staat los dan en
slechts dan als het buildsystem hier geen limitaties aan stelt. Op het
moment dat je build system "IDE" heet (Lees: Anjuta, KDevelop, Eclipse), dan
heet je editor ook Anjuta, KDevelop of Eclipse. Geen van al kunnen ze echt
nuttig overweg met projecten die door andere buildsystems worden beheerd.
Niet echt. Je kunt perfect je code editen in om het even welke editor naar
keuze en dan de nodige voodoo aanroepen van het plaatselijke buildsysteem.
Als die voodoo "eclipse" of "anjuta" of "kdevelop" heet in plaats van "make"
is dat uiteindelijk maar een detail. Een IDE is niet meer dan een (min of
meer functionele, afhankelijk van je smaak en wat je gewoon bent) editor met
een paar knopjes erin om compilers, linkers en debuggers aan te drijven.
Ik ben nog geen project tegengekomen waar het buildsysteem niet door make of
gelijkaardig aangedreven was (zoals gezegd, ik kom zelden in userspace, ieder
zijn vak) maar ik kan me niet voorstellen dat "eclipse build" of "eclipse
starten, koffie halen en op het knopje duwen" zoveel moeilijker is dan gewoon
iets als "make" tikken?
Post by Martijn van BuulMaar ja, kernelbouwers debuggen niet
Waar haal je dat? Linus is niet de enige "kernelbouwer".
Post by Martijn van Buul- en kernelbouwers gebruiken ook geen resource editors voor het bouwen van
dialogs.
Dat is waar. Daar kan ik inderdaad geen uitspraken over doen.
Post by Martijn van BuulEigenlijk heb je alleen Autotools overgeslagen. Op het moment dat developer
A pakket 1 gebruikt en developer B pakket 2 impliceert het al dat je
eigenlijk twee losstaande projecten aan het knutselen bent, die hooguit
shared code hebben. Anders gezegd: Als developer A een file toevoegt, moet
'ie alle IDE's die andere developers wensen te gebruiken *ook* langsgaan om
die file toe te voegen, want anders gaat het mis en gaan dingen uit de pas
lopen.
Niet echt. De file maakt deel uit van het "project" als het buildsysteem
(waar alle developers het over eens zijn en wat doorgaans "make" heet) de file
kan builden. Als een andere developer een heksentoer moet uitsteken om de
file in zijn editor zichtbaar te maken, dan lijkt me dat het probleem van de
gebruiker van die editor.
Eventueel zou de gebruiker van die editor de lijst van files die zijn editor
lust ook onder version control kunnen stoppen. Waarom editors een dergelijke
lijst van files nodig hebben, ontgaat me echter een beetje. Een directory is
toch zo'n lijst? Het feit dat de lijst binary is en uit structs dirent
bestaat en geen XML is, lijkt me juist eenvoudiger te zijn. Ongetwijfeld mis
ik weer een of andere nuance. Doch dit geheel terzijde.
Post by Martijn van BuulHet zal wel weer extreem wezen, maar ik vind dat een Bijzonder Stom Idee.
Ieder zijn mening. :-) Ik ben het over een aantal zaken niet met je eens (en
over een aantal zaken weer wel) maar ik respecteer je mening.
Post by Martijn van BuulPost by Philip PaepsIk heb in software teams gewerkt waar iedereen met andere editors werkte
Een IDE is geen editor, en een editor is geen IDE. Vrijheid van editor
betekent *afstand doen* van het gebruik van een IDE; het is onderling niet
te combineren. Je kunt best "vrijheid van editor" hebben (lees: je maakt
gebruik van een build system op leeftijd), maar "vrijheid van IDE" is van
den zotte, en leidt tot *heel* veeltijdsverlies en frustraties.
Met "een buildsysteem op leeftijd" bedoel je "een buildsysteem met maturiteit"
zoals bijvoorbeeld make, vergeleken met een eendagsvlieg zoals er dertien in
een dozijn zijn?
Wat wordt er in de IDE wereld dan wel precies onder een "buildsysteem"
verstaan? Ik beschouw het als een lijstje van files met hun dependencies en
de regels over hoe die dependencies ingevuld moeten worden. Vaak heb je dan
een programma dat dat lijstje eet en er recursief dan wel iteratief doorfietst
tot alle dependencies ingeguld zijn. Vaak heet dat programma "make", maar wat
mij betreft mag het ook "eclipse" heten of om het even wat.
Waarom heeft de keuze van het programma dat dependencies bouwt een invloed op
wat een developer gebruikt om code te schrijven? Ik kan me enigzins inbeelden
dat hij in het geval van een "buildsysteem" met een onduidelijk of wazig
gedocumenteerd dependency formaat een bepaalde omgeving nodig zou hebben om
zijn dependencies aan te geven (en als dat programma dat toevallig allerhande
features bevat waar hij geen boodschap aan heeft (zoals eventueel een editor),
so be it). Als op het einde van de dag de compiler de code lust en het
buildsysteem over het bestaan van de code afweet, lijkt me de klus geklaard?
Of die nu met twee tools in plaats van een geklaard is, doet volgens mij
weinig terzake.
Post by Martijn van BuulWat mij betreft is er niets mis met $editor + make, begrijp me niet
verkeerd, maar doe niet alsof het identiek is aan een IDE.
Ik beweer niet dat het *identiek* is. Ik beweer dat de twee situaties zeer
vergelijkbaar zijn. Het grote verschil is volgens mij dat make een lijst van
dependencies bijhoudt in een leesbare Makefile en dat makers van IDE graag met
hun eigen formaten op de proppen komen die enkel met hun IDE te beheren zijn.
Ongetwijfeld allemaal niets mis mee, en die features zijn ongetwijfeld zeer
boeiend en wenselijk, maar het bestaan van dergelijke omgeving doet niet af
aan het feit dat de developer zijn code nog steeds kan schrijven in om het
even welke editor die hij leuk vindt zonder daarmee om het even wie lastig te
vallen.
Post by Martijn van BuulPost by Philip PaepsOm er vim weer even bij te halen: ik heb de gewoonte om vim 'compiler'
scripts te gebruiken om build systems (en static analysis) te driven.
En daarmee geef je al aan dat *jij* op eigen houtje gaat besluiten dat het
buildscript vanaf nu vanuit Vim gevoerd gaat worden, en dat de "vrijheid"
van je collega's is beperkt tot "ik heb de vrijheid om het eens te zijn met
Philip en ook vim te gebruiken - of er mijn eigen vrije tijd iets anders
voor te bouwen".
Eh, nee. Zo gaat het niet. Ik stel vast dat het plaatselijke buildsysteem
met een bepaald commando aangedreven wordt en bepaalde output genereert.
Vervolgens schrijf ik een vim script voor mijn gebruik dat dat commando
uitvoert en de output voor mij analyseert op een manier die vim lust. Als er
anderen in het project ook vim gebruiken (en zelf geen dergelijke scripts
hebben) deel ik die graag met hen. Ongetwijfeld hebben alle Emacsers in het
project ook hun wrappers rond het buildsysteem. En ik heb zelfs samengewerkt
met mensen die Eclipse gebruikten, en dat werkte voor hen ook vlotjes.
Uiteindelijk kan iedereen vrolijk samenwerken omdat het buildsysteem zelf vaak
editor-neutraal is. Een Makefile en make -- je kunt ze in om het even wat
wrappen. Of het nu "Makefile" heet of "project file" en "make" of "eclipse",
doet toch weinig terzake? Als de build manager op de grote "build it" knop
kan drukken en (reproduceerbaar) een build kan afleveren waar de klant blij
mee is, maakt het toch niet uit als de tig developers op het project tig
verschillende editors gebruiken en elk hun eigen scripts (al dan niet hier en
daar onderling verdeeld) gebruiken?
Jij schijnt van mening te zijn dat iedereen op dezelfde manier zijn code moet
schrijven in venstertjes die er allemaal hetzelfde uitzien. Die mening deel
ik niet. Ik deel wel je mening dat iedereen op dezelfde manier op een
reproduceerbare wijze een build van de software moet kunnen afleveren. Maar
wat mij betreft doet iedereen dat in een omgeving die hem ligt.
Post by Martijn van BuulWant uit managementoogpunt is het natuurlijk van de zotte dat er onder
werktijd dubbel (of nog vaker!) werk wordt verricht enkel en alleen omdat er
wat eigenaardige developers rondlopen die niet in staat zijn om zich te
conformeren aan *een* standaard.
Wat management vooral boeit is dat het project op tijd klaar is. Het kan
management weinig schelen als een developer een halve dag zoet is om zijn
editor naar keuze rond het buildsysteem te wrappen als hij in die editor
vervolgens dubbel zo productief is dan in de editor die zijn buurman toevallig
gebruikt.
Een standaard hoort te liggen op een niveau waar het zinvol is. Het zinvolle
niveau om een standaard te leggen in een software development omgeving is op
de taal, de coding style en eventuele constraints en op de manier waarop de
verschillende source files tot binary files omgetoverd worden. Het heeft
weinig zin om een standaard te maken die oplegt met welke editor die source
files getikt moeten worden. Dat is een persoonlijke keuze van iedere
developer. Op voorwaarde dat de code die eruit komt in het buildsysteem past
en conformeert aan de coding rules, is er geen vuiltje aan de lucht.
- Philip
--
Philip Paeps Please don't email any replies
***@paeps.cx I follow the newsgroup.
The spot you are scrubbing on glassware is always on
the other side.