Qt och Debian eller Raspbian

@Sweedland:
Så länge du skriver POSIX-kompatibel kod bör det väl bara vara att ta med sig koden och kompilera om den på den andra plattformen? Nu börjar ju Raspberries bli ganska snabba, men jag gissar att du har lite mer kräm i din vardagsburk, så det lär ju vara bekvämare att göra på det viset än att skriva allt i/för Raspbian. Enda stora fördelen med att utveckla direkt på en Raspberry är väl att du omedelbart får en känsla för hur kvickt programmet känns på målplattformen.

Har kört Qt på ett par olika moduler och SBC men de har kört buildroot. Under utvecklingstiden korskompilerades det mestadels men innan faktiskt släpp i fält kompilerades det direkt på målenheten av olika skäl. Som mycket annat är det ofta summan av alla faktorer som avgör vad som är bäst för situationen. Funkar det fint för dig att kompilera på målenheten direkt så kör på det.

@Sweedland: Sätter man målsystemet och toolchain korrekt för korskompilering ser jag inte varför det skulle behöva versionhanteras i flera olika system då programmet kompileras på arbetsstationen men sedan körs direkt på målsystemet. Poängen är att du ska programmera något som fungerar på målsystemet och inte nödvändigtvis på den platform du använder för att skriva koden.

Det är framförallt när det börjar röra sig om stora komplexa program som jag skulle undvika att använda en IDE på Raspberry av lite olika anledningar. Som den koden jag sitter och petar i nu ligger runt 380000 rader på ca 65+ filer och tar ca 38s att kompilera på en arbetsstation med Xeon. Skulle troligtvis ta över 3-4 minuter att kompilera på en Raspberry vilket är lite tråkigt.

@Sweedland: Problemet du tar upp handlar mer om att kompilator/sdk blir uppdaterad över tid och äldre kod inte funkar att kompilera längre. Det problemet har man överallt, C# som i C på någon liten obskyr PIC10. Såvida man inte tar en fullständig backup med alla verktyg, Windows/Linux, fysisk dator osv så kommer det problemet alltid att kvarstå. Det är väl där @Det Otroliga Åbäket tips kommer väl till pass, skriv POSIX eller åtminstone ANSI/ISO kod. Då behöver man justera minimalt i koden för den nya sdk (vanligtvis GPIO/UART/Timers etc).
Klassikern är väl när Microchip gick från MPLAB 8 till MPLAB X. En sörja utan dess like. Likaså när Renesas gick från HEW till E2.

Här på företaget kör vi båda delarna (inte allt mot Raspberry utan även mot moduler med MIL-STD krav). Vissa script och program osv blir väldigt specifika till den hårdvara du arbetar mot och då jobbar man ofta direkt på den hårdvaran.

Dit jag vill komma är att det är viktigt att välja sin utvecklingsmiljö utifrån krav, behov och vad man är bekväm med helt enkelt. Är det att köra MS Visual Studio och korskompilera så gör man det, är det Qt så kör man på det istället. Fungerar det bra eller rent av krav att jobba direkt på hårdvaran så gör man det.
Att säga "det här verktyget måste du jobba i" och som standard på ett företag funkar nog jättebra när till allt utom utveckling till MCU:er. Det är i princip olika miljöer från varje tillverkare. En del har bra samarbete med företag som IAR och Keil, andra har det inte. Vissa fungerar bra med platform.io, andra inte, har sett ett par sådana "standardiseringsplatformar" komma och gå i mina dagar.

Slutsats, jag håller med dig. Det går inte att säga att Qt eller något annat ska vara standard. För det finns ingen standard när det kommer miljöer från de olika tillverkarna. Håller man sig till POSIX så minskar arbetet när bakåtkompabilitet bryts i utvecklingsmiljön.

@Sweedland: Jag skulle säga att om ni gör ett program idag som i framtiden kommer behöva ett grafiskt skal kanske man kan titta på att göra något form av "dll". Om det sedan anropas från ett console-program eller via grafiskt interface spelar då mindre roll. Men har man inte pysslat med (shared?) libraries tidigare får man se till tiden det tar att sätta sig in detta om det är rimlig väg att gå.