XCode-Alternativen? speziell unter Linux?

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • XCode-Alternativen? speziell unter Linux?

    Gibt es eine brauchbare IDE für Objective-C außer XCode?
    Wenigstens einen Editor mit Syntax-Highlighting?
    Lauffähig mindestens unter Linux; Windows zusätzlich wäre nett; OS X reicht leider nicht.

    Ich will Objective-C mit GNUstep-Runtime in einem embedded-Projekt einsetzen.
    Alles außer Objective-C läßt sich leidlich mit Eclipse abdecken.

    Dankbar für jeden sachdienlichen Hinweis!

    Gruß
    - kisch



  • Danke, gritsch.
    Probiert und für sehr seltsam befunden.
    Leider hat das Ding hat komische Wechselwirkungen mit einem normalen Linux-Desktop, zB öffnen sich Popup-Menüs hinter dem zugehörigen Fenster. Das NextStep-Feeling wird noch dazu vom Team als "archaisch" empfunden.

    Ich bin inzwischen auf einen Patch (oha) für KDevelop (oh je) gestoßen, den werden wir wohl als nächstes evaluieren...

    gruß kisch

  • Original von kisch
    Ich will Objective-C mit GNUstep-Runtime in einem embedded-Projekt einsetzen.

    Kannst Du da etwas Genaueres drüber sagen? Ich mache das seit Jahren.



    Probiert und für sehr seltsam befunden.
    Leider hat das Ding hat komische Wechselwirkungen mit einem normalen Linux-Desktop, zB öffnen sich Popup-Menüs hinter dem zugehörigen Fenster. Das NextStep-Feeling wird noch dazu vom Team als "archaisch" empfunden.

    Ich bin inzwischen auf einen Patch (oha) für KDevelop (oh je) gestoßen, den werden wir wohl als nächstes evaluieren...

    gruß kisch
    Das mit den Wechselwirkungen liegt am Window-Manager. GNUstep verträgt nicht jeden X-beliebigen.

    Das mit dem "arachaisch" finde ich persönlich auch so - andere lieben das NeXT-Design... Ich glaube es gibt inzwischen auch Theming.

    Der Vorteil von GNUstep ist daß man Cocoa-kompatible Apps incl. NIB-Files (GORM) schreiben kann und später ein Xcode-Projekt drum herumbauen. Aber wenn Du ein Foundation-Tool erstellen willst braucht es das natürlich nicht...

    -- hns

  • Original von hns
    Original von kisch
    Ich will Objective-C mit GNUstep-Runtime in einem embedded-Projekt einsetzen.

    Kannst Du da etwas Genaueres drüber sagen? Ich mache das seit Jahren.



    Ehrlich? Großartig! Kann man Dich als Referenz zitieren? :)

    Mein System besteht aus ein bis zwei Dutzend embedded-Linux Hosts in zwei Klassen verschiedener Funktionalität. Die Hosts müssen einiges über Netzwerk austauschen. Auf dem einzelnen Host gibt's auch voraussichtlich ein ganzes Set verschiedenener Prozesse. Die Schnittstellen sollen objektorientiert sein, und man soll im Laufe der Entwicklung auf einfache Weise den Ort (Prozess, Host), wo ein Objekt läuft, verschieben können.

    Bei dieser Menge von Netzwerk-Interfaces erscheinen mir die Distributed Objects höchst attraktiv. Alternativen wären Corba oder ICE, aber wenn ich eh' die remote API in einer IDL schreiben muß, dann kann ich dafür genausogut Obj-C als "IDL" mit Funktion nehmen (performed auch besser, wenn ein Objekt hinterher wg. Performance doch im gleichen Prozeß aufgerufen wird, als wenn das über Corba abgewickelt würde). Andere Alternativen:
    Linux D-Bus - sagen sogar von sich selbst, sie seien noch unperformanter als Corba
    Java RMI - geht erstmal nur mit Java
    Ruby DRB - geht erstmal nur mit Ruby.
    Corba bekommt zusätzliche Minuspunkte wg. Komplexität, und weil ich schon einmal ein großes Corba-Projekt habe scheitern sehen (von frühem KDE und Gnome zu schweigen, die auch beide davon ab sind). ICE benutzt wie gesagt auch eine IDL, und es scheint nicht viele praktische Erfahrungen damit zu geben.

    Als Implementationssprache insgesamt ist Obj-C zu wenig mainstream, leider. Also wird's Obj-C++, Obj-C auf die Schnittstellen beschränkt.

    Tja, aber das ProjectCenter hat hier leider wohl schlechte Karten.
    XCode wäre akzeptabel, aber ich habe den einzigen Mac im Projekt...

    gruß kisch

  • Original von macfreakz
    Eine Einleitung, die ich damals geschrieben habe:
    macentwicklerwelt.net/doku.php?id=wiki:cocoaonlinux


    Hei, Du bist der mit der XCode-Crosscompile-GNUstep-Zaurus-Umgebung!
    Gute Sache, da habe ich auch ein wenig mit herumgespielt.
    Auf jeden Fall vielen Dank für diese ausführliche Anleitung.

    Ich würde auch am liebsten die Entwicklung auf Macs machen, XCode als IDE und cross bauen.
    Wäre allemal das praktischste.
    Leider leider entspricht das nicht den Kunden-Requirements in einer Windows-Welt.

    gruß kisch

  • Original von kisch
    Mein System besteht aus ein bis zwei Dutzend embedded-Linux Hosts in zwei Klassen verschiedener Funktionalität. Die Hosts müssen einiges über Netzwerk austauschen. Auf dem einzelnen Host gibt's auch voraussichtlich ein ganzes Set verschiedenener Prozesse. Die Schnittstellen sollen objektorientiert sein, und man soll im Laufe der Entwicklung auf einfache Weise den Ort (Prozess, Host), wo ein Objekt läuft, verschieben können.

    Bei dieser Menge von Netzwerk-Interfaces erscheinen mir die Distributed Objects höchst attraktiv.
    genau dafür wurde es entwickelt.

    Performance: die eigentliche Kommunikation hängt nur von der Größe der ausgetauschten Objekte ab und dem Netzwerk, da es keinen zentralen Vermittler gibt (außer für die Servernamensauflösung). Methodenaufrufe sind objektgrößenunabhängig (außer den Parametern), da nur eine Referenz auf das Objekt und der Methodenname übertragen wird (das kann man ja über die byref und bycopy-Attribute steuern).

    GNUstep-DO ist auf dem Netz leider nicht mit Mac/Cocoa DO kompatibel - vom API her aber im wesentlichen schon. GNUstep hat den gdomap-Daemon für die Namensauflösung, während Cocoa entweder Mach-Namen oder ZeroConf benutzt. D.h. man kann das System mit einem oder mehreren Macs ausprobieren und dann auch auf einem oder mehreren GNUstep-Maschinen laufen lassen.

    Ich bin schon seit längerem dabei das für mySTEP umzubauen, so daß es zum Mac kompatibel wird, aber da ist noch einiges an Reverse Engineering zu machen und es ist unklar ob es jemals kompatibel sein wird (weil die Objektserialisierung ja auch 100%ig zusammenpassen müßte).

    -- hns

  • Original von hns
    GNUstep-DO ist auf dem Netz leider nicht mit Mac/Cocoa DO kompatibel

    ...das schadet erstmal nicht

    - vom API her aber im wesentlichen schon.

    Das ist wichtiger.


    GNUstep hat den gdomap-Daemon für die Namensauflösung, während Cocoa entweder Mach-Namen oder ZeroConf benutzt.

    Wir werden auf jeden Fall Bonjour verwenden. Das läuft auch bereits.
    Eine vollständig dynamische Naming-Datenbank, wie gdomap bereitstellt, werden wir auch nicht brauchen. Ich denke, wir lassen pro Host einen Bonjour-Prozeß laufen und streuen die Informationen über neu entdeckte Hosts lokal über Notifications an interessierte Prozesse, die dann gezielt eine DO-Verbindung zum neuen Host aufmachen können.

    Der gdomap-Dämon selber ist auch nicht wirklich für dynamische Netzwerk-Setups geeignet. Er versucht einmalig beim Start, andere gdomap-Instanzen im Netz durch sukzessiven IP-Scan (!) über den lokalen Netzwerkbereich und abschließend Port-Probe zu finden. Da ist das Multicast-Protokoll von Bonjour doch um einiges fortschrittlicher.


    Ich bin schon seit längerem dabei das für mySTEP umzubauen, ...

    Dann bis DU derjenige mit der XCode-Crosscompile-GNUstep-Zaurus-Umgebung!

    Ja, wie gesagt, ein respektables Projekt.

    Du verwendest ja das X-Backend von GNUstep, richtig?
    Seit MacOS X habe ich mich immer gefragt, warum die Jungs dort kein OpenGL-Grafik-Backend in Angriff nehmen wollten?

    gruß kisch

  • Original von kisch

    Ich bin schon seit längerem dabei das für mySTEP umzubauen, ...

    Dann bis DU derjenige mit der XCode-Crosscompile-GNUstep-Zaurus-Umgebung!
    Ja.
    Ja, wie gesagt, ein respektables Projekt.
    Danke!
    Du verwendest ja das X-Backend von GNUstep, richtig?
    Seit MacOS X habe ich mich immer gefragt, warum die Jungs dort kein OpenGL-Grafik-Backend in Angriff nehmen wollten?
    Nicht mehr - ich habe inzwischen mein eigenes X-Backend ("nur" ca. 3000 Zeilen Code - das ist weniger als NSString). Das abstrahiert X11 auf PDF-Primitive. Der Vorteil: Drawing kann sowohl auf einen NSScreen als auch NSPrinter gehen.

    OpenGL hat das Problem dass man es erst mal auf dem Embedded Device haben muß... Beim Zaurus gab es zunächst nicht mal einen X-Server. Das OpenMoko-Device bringt immerhin einen mit.

    Maintream GNUstep setzt jetzt auf Cairo (was für Embedded-Systeme ohne FPU auch problematisch ist).

    -- hns

  • im Prinzip versteht doch jede IDE Obj-C. Brauchst ja nur Syntax Highlighting zu ändern. Aber Anjuta, Eclipse, Kdevelop, Netbeans ist so das umgänglichste.

    Dann eben mit autoconf ggf. ein autoscript erstellen. Das kann aber KDevelop und Co auch selber.

    Früher hat Debian sid bei Anjuta etwas gesponnen aber das funktioniert jetzt auch bei etch/sid ganz passabel.

    Aber an Xcode kommt meines erachtens nur Netbeans ran. Zwar auch etwas stockend durch Java aber eine feine Java IDE.

  • Original von tom
    Brauchst ja nur Syntax Highlighting zu ändern.


    Dachte ich mir auch. Nimm Eclipse, bastel ein bißchen Obj-C Higlighting hinzu.
    Dummerweise muß man bei Eclipse zu diesem Zwecke allerdings einen kompletten Parser für die Sprache implementieren --- ist mir ein bißchen zu aufwendig. Zum Trost hätte man dann zwar auch gleich Klassenbrowsing und Code Completion mit erschlagen. Aber dieser Moloch von Eclipse-Sourcebaum ist doch etwas abschreckend.


    Dann eben mit autoconf ggf. ein autoscript erstellen. Das kann aber KDevelop und Co auch selber.


    Autotools lassen wir lieber aus. Wir haben eine feste Zielplattform, da braucht's das nicht.


    Aber an Xcode kommt meines erachtens nur Netbeans ran.

    Guter Hinweis, danke!
    Ich dachte immer, das ist rein für Java.
    Gerade mal nachgeschaut, und kann aber auch C/C++ inklusive Source-Debugging.
    Ich probier's mal aus, vielleicht ist es da einfacher, das Syntax Highlighting zu ergänzen.

    gruß kisch

  • im Javamagazin war mal eine Serie von "Tutorials" wie man Plugins für Netbeans baut. Ich weis nicht ob man dies auch online lesen kann. Müsste so die Zeit um den letzten Dezember gewehsen sein.

    Netbeans ist schon eine tolle IDE. Für Java Enterprise Anwendungen ist es einfach unschlagbar. Und man brauch noch nicht einmal die erweiterte Version von Sun :)

    und das beste. Sogut wie jede Platform