Utvikling på Linux platform

[HDSoftware]

Du klarer begge de forskjellige oppgavene i begge, men hvorfor gå når man kan stråletransportere seg ;-)

 

Min umiddelbare reaksjon mot disse løsningene, inklusivt Visual studio, code warrior, xcode etc -- er at de fort faktisk kommer i veien for hva du ønsker å gjøre på en effektiv måte.

Kunne du gitt et par eksempler på dette?

 

Det er også verdt å merke seg at opprinnelig Unix programflyt er svært forskjellig fra hva man er vant til fra Windows.

Nå følger jeg deg ikke helt. Et program er da i utgangspunktet ikke OS avhengig, med mindre man benytter kanaler gjennom OS spesifike funksjoner, men dette er vel strengt tatt det samme som å bruke biblioteker, og vil i så fall være transparente fra OS til OS. Litt usikker med hva du mener når du sier et program er SHELL orientert?. Mine programmer er uavkortet grafiske og enten det gjelder tekstbehandling, regneark eller annet så ser jeg ikke helt hvor SHELL kommer inn i bildet. Nå kal det innrømmes at min kjennskap til Linux er någet begrenset og det er derfor jeg spør.

[Dj_Offset]

Du klarer begge de forskjellige oppgavene i begge, men hvorfor gå når man kan stråletransportere seg ;-)

Min umiddelbare reaksjon mot disse løsningene, inklusivt Visual studio, code warrior, xcode etc -- er at de fort faktisk kommer i veien for hva du ønsker å gjøre på en effektiv måte.

Kunne du gitt et par eksempler på dette?

 

Jeg har jobbet mye med utvikling av programvare på embedded platformer, som mobiltelefoner, spillkonsoller, og andre rare "dingser", såvel som mer tradisjonelle applikasjoner for unix, windows og mac.

I utgangspunktet jobber jeg med C/C++ kode, og etter en del år i bransjen kan jeg nevne i fleng...

 

Et eksempel, vi fant ut at en kompilator vi hadde fått fra en kunde produserte feil kode for enkelte funksjonskall dersom det fantes flere argumenter enn ledige registere på arkitekturen. Problemet kunne ikke løses ved å be om en ny kompilator fra produsenten siden vi ikke hadde tid til å vente på dette.

Hvordan løser man da et slikt problem, hvis en da ikke ønsker å endre koden?

Vi endret kompileringen til å produsere assembly filer (istedet for objektfiler), brukte et spesialskrevet verktøy skrevet i Perl for å "fikse" assembler koden, før vi kompilerte assembler til objektfiler.

Problemet løst, med to nye linjer en Makefile.

Riktignok økte kompileringstiden med 5-10%, siden vi kjører to nye prosesser per kompilerte fil...

 

Andre ting som ofte blir gjort:

 

* automatisk distribuering av kompileringsjobber (joda, du kan *kjøpe* incredibuild for visual studio), og xcode har noe lignende innebygget. Jeg bruker icecream som integrerer fint med gcc, og distcc som integrerer mot noen andre kompilatorer.

* På en build server er det praktisk med ccache, siden samme fil har en tendens til å bli kompilert flere ganger.

* Det er ofte praktisk å "massere" objektfiler etter at de er produsert, for eksempel obfuskere symboler, eller skrive om symboler.

* Biblioteket skal ikke kunne kompileres og brukes før alle autotestene passerer.

 

Det er også verdt å merke seg at opprinnelig Unix programflyt er svært forskjellig fra hva man er vant til fra Windows.

Nå følger jeg deg ikke helt. Et program er da i utgangspunktet ikke OS avhengig, med mindre man benytter kanaler gjennom OS spesifike funksjoner, men dette er vel strengt tatt det samme som å bruke biblioteker, og vil i så fall være transparente fra OS til OS. Litt usikker med hva du mener når du sier et program er SHELL orientert?. Mine programmer er uavkortet grafiske og enten det gjelder tekstbehandling, regneark eller annet så ser jeg ikke helt hvor SHELL kommer inn i bildet. Nå kal det innrømmes at min kjennskap til Linux er någet begrenset og det er derfor jeg spør.

 

Hvis du tenker på dekstop applikasjoner som regneark, tekstbehandling, nettleser, fotoredigering osv, så har dette en tendens til å være grafiske programmer som presenterer en "alt i ett løsning", og disse ser for det meste like ut over hele fjøla.

 

Unix har en filosofi hvor små verktøy gjør helt spesialiserte oppgaver, og hvor disse kan settes sammen til å løse større problemer.

 

La oss si at du har et spesielt use-case for applikasjonen du utvikler:

Du ønsker å lage en funksjon som sjekker om det finnes oppdateringer for en komponent av programmet ditt, f.eks. en gang i uken, eller hver gang programmet starter (e.l.), og om det finnes vil du laste den ned, sjekke digital signatur og til slutt installere komponenten automatisk.

Hvis du jobber i filosofien "alt-i-ett-løsning", og jeg ber deg estimere hvor lang tid tar det å utvikle denne funksjonaliteten (inkludert kvalitetstesting). Hvor mange dager/uker/måneder med arbeid vil du se for deg at dette tar?