Mac Neuling möcht C Programmieren für Sysprog VL

"make" ist sicher erfolgreich durchgelaufen? (poste lieber mal den output).
starten tust du das ganze wie ueblich unter unix-derivaten mit

./my_binary

"my_binary" musst du natuerlich durch den namen deiner ausfuehrbaren datei ersetzen. ich rate mal es liegt in deinem fall an dem './'.
[edit]
der vollstaendigkeit halber erwaehe ich noch, dass du vorher vielleicht ein

cd path/to/my/binary

machen musst.
[/edit]

Zitat von gernot

Wie ich jetzt mit dem XCode hantieren soll ist mir sowieso unklar.

XCode ist eine komplette Entwicklungsumgebung - für den Anfang würde ich XCode bestenfalls zum Schreiben des Source-Code verwenden, alles andere über die Kommandozeile. So bekommt man einfach mehr Verständnis dafür was hinter den Kulissen abläuft als wenn man in XCode ein Projekt erstellt und das dann per Knopfdruck kompilieren und ausführen lässt.
Habe Sysprog (und einige andere LVAs) auch unter Mac OS X gemacht, bin mit dieser Strategie immer bestens gefahren

Mac OS X kann keine message queues, das könnte in Sysprog ein Problem sein (je nachdem, in welche Gruppe man kommt).

Generell find ich Xcode einfacher als Makefiles schreiben etc (besonders bez. autoconf/automake), allerdings für sysprog solltest du eher diese verwenden.

Zitat von hal

Mac OS X kann keine message queues, das könnte in Sysprog ein Problem sein (je nachdem, in welche Gruppe man kommt).

Generell find ich Xcode einfacher als Makefiles schreiben etc (besonders bez. autoconf/automake), allerdings für sysprog solltest du eher diese verwenden.

also, bei meinem mac os x kann ich sehr wohl message queues verschicken. allerdings bleibt es sowieso nicht aus am uni server zu testen, besser noch gleich drauf zu entwickeln, weil es doch zwei verschiedene betriebssysteme sind. ich zb. hatte am mac os öfters bus fehler, via ssh nicht. hab kurz gegoogelt und das soll eine mac eigene sache sein, zb...

ps.: ich hab noch xcode installiert und alles ging so weit...

Zitat von hal

Generell find ich Xcode einfacher als Makefiles schreiben etc (besonders bez. autoconf/automake)

ich kenn Xcode nur soweit als dass ich es installiert habe um den gcc zu bekommen, also entschuldige meine unwissenheit, aber verlierst du damit nicht die tollen vorteile der autotools? wie portabel ist dann das package?

wenn man nicht zu sehr vom normalen weg (99% aller projekte) abkommt, dann sind die autotools schon eine feine sache. und wenn man mal ein paar projekte hinter sich hat, dann gehts wirklich halbwegs einfach und sicher schneller als Makefiles haendisch zu schreiben. aber wehe dem, der etwas ungewoehnliches braucht, dann werden sie schnell zur autohell. ich selbst hab gestern auch einige zeit verschissen bis ich 3rd party Makefiles (fuer ein linux kernel modul) in die autotools integriert hatte. aber ja, es hat letztendlich funktioniert. von mir also ein autotools ftw!

Zitat von Kampi

ich kenn Xcode nur soweit als dass ich es installiert habe um den gcc zu bekommen, also entschuldige meine unwissenheit, aber verlierst du damit nicht die tollen vorteile der autotools? wie portabel ist dann das package?

Xcode ist überhaupt nicht portabel. Wenn du Linux-Software entwickeln willst, ist das Programm natürlich nicht geeignet.
Wenn du allerdings für den Mac entwickeln willst, hast du andere Anforderungen. Nachdem die Plattform genau definiert ist (was an libs vorinstalliert ist etc) brauchst du keine detection dafür. Du kannst im Xcode eine Minimumversion von Mac OS X definieren, und der Compiler wird sich dann weigern, Dinge zu kompilieren, die auf der Platform noch nicht gelaufen sind, auch wenn du auf einer neueren Version bist, wo diese Dinge schon gehen. Das ist die einzige Portabilität, die du unter Mac OS X brauchst.

Zitat

wenn man nicht zu sehr vom normalen weg (99% aller projekte) abkommt, dann sind die autotools schon eine feine sache.

Ich hab in se/linux die autotools kennengelernt, und es war die Hölle. Nicht nur, dass die Fehlermeldungen meistens absolut nichtssagend sind, die Konfigurationsfiles sind auch oft weder aufwärts- noch abwärtskompatibel, was natürlich besonders toll ist, wenn man fremde Pakete bekommt, wo man das configure-script neu generieren muss (zB weil mans aus dem repository bekommen hat). Wenn man Glück hat, ist die Version spezifiziert im autogen-script oder INSTALL, wenn man Pech hat darf man herumprobieren.

Zitat von hatti

also, bei meinem mac os x kann ich sehr wohl message queues verschicken.

Hmm evtl ist das jetzt neu implementiert worden, ich hab ja damals auf Mac OS X 10.3 gearbeitet glaub ich. Lang, lang is her
Damals gabs nichtmal dlopen, das hams inzwischen auch nachprogrammiert.

Zitat

ich zb. hatte am mac os öfters bus fehler, via ssh nicht.

Sowas ist oft ein Hinweis auf einen Bug im Code, der nur auf einer Plattform zufällig keine Auswirkungen hat. Oder auf einen Bug in einem System, was aber eher seltener vorkommt (speziell wenn man so an der Oberfläche bleibt wie in sysprog).

Zitat von hal

Xcode ist überhaupt nicht portabel. Wenn du Linux-Software entwickeln willst, ist das Programm natürlich nicht geeignet.

naja, nicht ganz so toll. es ging mir darum portable programme zu schreiben. mit den autotools deckt man halt im normalfall gleich sehr viele betriebssysteme ab, ich denke ich muss jetzt nicht 10 verschiedene aufzaehlen.

Zitat von hal

Wenn du allerdings für den Mac entwickeln willst, hast du andere Anforderungen.

in der tat. point taken. so einem das reicht wird man wohl mit Xcode gluecklich(er).

Zitat von hal

Ich hab in se/linux die autotools kennengelernt, und es war die Hölle.

ich genau so und ja, es war die hoelle. aber wie ich schon sagte gehn auch autotools mit ein bissl erfahrung ganz flott von der hand. vergleich es vlt. mit latex. am anfang zach, wenn man es kann ist es nett.

Zitat von hal

Nicht nur, dass die Fehlermeldungen meistens absolut nichtssagend sind, die Konfigurationsfiles sind auch oft weder aufwärts- noch abwärtskompatibel, was natürlich besonders toll ist, wenn man fremde Pakete bekommt, wo man das configure-script neu generieren muss (zB weil mans aus dem repository bekommen hat). Wenn man Glück hat, ist die Version spezifiziert im autogen-script oder INSTALL, wenn man Pech hat darf man herumprobieren.

bei den fehlermeldungen bin ich bei dir, aber es ist imo etwas unfair den autotools die schuld dafuer zu geben dass der "distributor" der sourcen nicht weisz was er zu dokumentieren und mitzuliefern hat. das ist die unfaehigkeit des entwicklers und nicht die der autotools.

Zitat von Kampi

aber es ist imo etwas unfair den autotools die schuld dafuer zu geben dass der "distributor" der sourcen nicht weisz was er zu dokumentieren und mitzuliefern hat. das ist die unfaehigkeit des entwicklers und nicht die der autotools.

Keine Abwärts- bzw. Aufwärtskompatiblität ist der Fehler des Distributors? Aber nur wenn man es als Fehler ansieht, dass er überhaupt die autotools verwendet.

Zitat von hal

Keine Abwärts- bzw. Aufwärtskompatiblität ist der Fehler des Distributors?

noe, natuerlich nicht. vielleicht habe ich mich zu unklar ausgedrueckt. ich habe da eher an den fall gedacht, dass im tar-ball wichtige dateien (zb configure.ac) fehlen und man so nicht sinnvoll weiter arbeiten kann.

Zitat von Kampi

noe, natuerlich nicht. vielleicht habe ich mich zu unklar ausgedrueckt. ich habe da eher an den fall gedacht, dass im tar-ball wichtige dateien (zb configure.ac) fehlen und man so nicht sinnvoll weiter arbeiten kann.

Äh, keine Ahnung wie du auf die Idee gekommen bist, dass ich über das geredet hab. Um irgendwelche wichtigen fehlenden Dateien ist es doch überhaupt nicht gegangen?

Zitat von hal

Äh, keine Ahnung wie du auf die Idee gekommen bist, dass ich über das geredet hab. Um irgendwelche wichtigen fehlenden Dateien ist es doch überhaupt nicht gegangen?

dann hab ichs wohl falsch verstanden. diesen teilsatz hab ich eben so interpretiert:

Zitat von hal

was natürlich besonders toll ist, wenn man fremde Pakete bekommt, wo man das configure-script neu generieren muss (zB weil mans aus dem repository bekommen hat).

bei "configure-script neu generieren" hab ich eben an ein fehlendes configure.ac gedacht.

is aber wirklich sowas von wurscht. ich mag autotools, du nicht. so what?
was mich noch interessiern wuerde ist was du dann fuer tools verwendest falls du code schreibst der nicht nur aufm mac laufen soll. (so du solchen code fabrizierst). cmake? oder gibts da noch was besseres das mir noch nicht untergekommen ist? im FOSS bereich haben ja die autotools einen riesigen marktanteil und im prinzip bauen ja recht viele paketmanager in einer gewissen weise auf die autotools auf und wenn es nur darum geht einfach binaerpakete ausm source zu bauen ist man schon gluecklich wenn man die klassiche "./configure && make" chain vor sich hat.

Zitat von Kampi

bei "configure-script neu generieren" hab ich eben an ein fehlendes configure.ac gedacht.

In source revisioning-trees sind generierte files nie drinnen, d.h. du musst da immer autoconf/automake ausführen, wenn das Paket diese verwendet.

Ich hab schon öfters development-Versionen von diversen Paketen verwenden müssen, da kommt man mit sowas viel in Kontakt.

Zitat

is aber wirklich sowas von wurscht. ich mag autotools, du nicht. so what?

Naja, wenn dus verwendest, zwingst du das ganze auch jedem auf, der deine Software verwenden will, insofern isses nicht nur ganz deine Entscheidung.

Zitat

was mich noch interessiern wuerde ist was du dann fuer tools verwendest falls du code schreibst der nicht nur aufm mac laufen soll.

Das passiert ganz selten, aber wenn verwend ich meistens einfach normale (handgeschriebene) Makefiles.

Falls ich wirklich mal was besseres brauch, werd ich mir vermutlich mal cmake anschauen, aber dazu war bisher die Notwendigkeit einfach noch nicht da.

Zitat

wenn es nur darum geht einfach binaerpakete ausm source zu bauen ist man schon gluecklich wenn man die klassiche "./configure && make" chain vor sich hat.

Ja, aber nur "make" ohne irgendwas ist auch ganz nett. 9/10 der Checks, die autoconf macht sind sowieso komplett unnötig und im code gar nicht integriert.

Zitat von hal

In source revisioning-trees sind generierte files nie drinnen, d.h. du musst da immer autoconf/automake ausführen, wenn das Paket diese verwendet.

Ich hab schon öfters development-Versionen von diversen Paketen verwenden müssen, da kommt man mit sowas viel in Kontakt.

na komm schon, fuer wie unfaehig haeltst du mich dass du glaubst das ist mir neu? ich dachte eben an den fall dass jemand der autotools verwendet hat dann eben die configure.ac nicht mitgeliefert hat. sollte bei "make dist" nicht passieren, ich hab aber schon ein paar solcher tarballs erlebt. deshalb hab ich ja in dem fall auch mit der unfaehigkeit des entwicklers argumentiert. ich denke so sollte meine argumentation klarer sein. dir ist es aber um die auf-/abwaertskompatibilitaet gegangen und da hast du schon recht, man endet schnell mit X versionen der autotools.

Zitat von hal

Naja, wenn dus verwendest, zwingst du das ganze auch jedem auf, der deine Software verwenden will, insofern isses nicht nur ganz deine Entscheidung.

wenn mich der auftraggeber/das projekt ansich zwingt etwas anderes zu verwenden, dann muss ich das notgedrungen tun. wenn ich aber die freie wahl habe, dann nehme ich das meiner meinung nach beste tool. und das sind bei mir, wie bei vielen anderen, eben die autotools. du drueckst mir so gesehen ja dann auch deine handgeschriebenen Makefiles aufs aug obwohl ich lieber autotools haette. das ist in beiden faellen einfach "take it or leave it".

Zitat von hal

Das passiert ganz selten, aber wenn verwend ich meistens einfach normale (handgeschriebene) Makefiles.

das geht lange schneller, lange geht es gut. macht man spezielleres und will grausliche unixe auch an board holen geht es leicht in die hose. das hat mir zumindest meine erfahrung gezeigt. und hat ein projekt eine gewisse schwellengroesze erreicht, die nicht gerade grosz ist, dann ist man mit autotools so und so schneller und komfortabler unterwegs. es sind oft schon kleinigkeiten die handgeschriebene Makefiles ungut machen koennen.

wo werden bei dir die binaries und manpages installiert? hast du das hardcoded?

Zitat von hal

Ja, aber nur "make" ohne irgendwas ist auch ganz nett. 9/10 der Checks, die autoconf macht sind sowieso komplett unnötig und im code gar nicht integriert.

hm, bei mir tut autoconf eigentlich das was ich ihm sage. ein paar standardchecks sind dabei, aber dann teste ich ja ohnehin gezielt auf die sachen die ich brauche. also wie du auf 9/10 kommst ist mir schleierhaft. checks fuer die es keine macros gibt schreibt man sich btw im guenstigsten falle mit einer zeile code. (hab extra in einem meiner projekte nachgeschaut).

abschlieszend noch dieser link. liegts vlt. dran dass es GNU-tools sind? ersetz beim lesen einfach GNU durch Apple und autotools durch itools, vlt. wirst du dann auch noch ein fan davon

Zitat von Kampi

na komm schon, fuer wie unfaehig haeltst du mich dass du glaubst das ist mir neu? ich dachte eben an den fall dass jemand der autotools verwendet hat dann eben die configure.ac nicht mitgeliefert hat. sollte bei "make dist" nicht passieren, ich hab aber schon ein paar solcher tarballs erlebt.

Ich hab aber nicht von tarballs gesprochen, sondern wenn man direkt das repository anzapft.

Zitat

wenn mich der auftraggeber/das projekt ansich zwingt etwas anderes zu verwenden, dann muss ich das notgedrungen tun.

Meine Auftraggeber spezifizieren meistens nur, dass es schön blinken soll, der Rest ist denen egal...

Zitat

das geht lange schneller, lange geht es gut. macht man spezielleres und will grausliche unixe auch an board holen geht es leicht in die hose. das hat mir zumindest meine erfahrung gezeigt. und hat ein projekt eine gewisse schwellengroesze erreicht, die nicht gerade grosz ist, dann ist man mit autotools so und so schneller und komfortabler unterwegs. es sind oft schon kleinigkeiten die handgeschriebene Makefiles ungut machen koennen.

Ja, da hast du eh recht. Hab ja geschrieben, dass ich für Linux nur Minitools programmiert hab bisher.

Zitat

wo werden bei dir die binaries und manpages installiert? hast du das hardcoded?

make install implementier ich meistens nicht.

Zitat

liegts vlt. dran dass es GNU-tools sind?

Nein, sicher nicht.

Zitat

ersetz beim lesen einfach GNU durch Apple und autotools durch itools, vlt. wirst du dann auch noch ein fan davon

Apple würd drum herum ein schönes GUI basteln, wo man die ganze Geschichte mit ein paar Mausklicks erledigt hat.