4. automake &co vs. Do it yourself

automake &co vs. Do it yourself

  • T

    Schönen Abend allerseits,

    Ich räume hier gerade in einigen kleineren von mir mit KDevelop erstellten Projekten auf. Nun liegen in einigen die Gleichen Klassen in CPPs herum. Also dachte ich mir: Warum die nicht an einer stelle sammeln und überall benutzen - klar, sonst muß ich ja Änderungen nachziehen. Gesagt getan, alle Quellfiles in einen Ordner gepackt und das Makefile mofifiziert :

    REVERSI_PATH = ../../../Reversi
reversi_sdl_SOURCES = reversi_sdl.cpp REVERSI_PATH/Game.cpp REVERSI_PATH/Stone.cpp FreeType.cpp REVERSI_PATH/Player.cpp REVERSI_PATH/PlayField.cpp gdiwrappersdl.cpp REVERSI_PATH/GdiWrapper.cpp

    Die dann mit automake aktualisierten Makefiles scheinen auch zu stimmen, (der neue Pfad REVERSI_PATH wird eingetragen), aber Ich bekomme den komischen Fehler:

    NONE:0: /usr/bin/m4: `m4_symbols' from frozen file not found in builtin table

    mhh m4 macht doch eigentlich nur Ersetzungen in den Eingabefiles und damit hat die Änderung doch gar nichts zu tun. Was nun? Ich könnte einfach ein eigenes Makefile Schreiben. Das von KDEveleop generierte ist schon ein bisschen unübersichtlich (das Ultimate - Makefile aus dem Forum käme mir da in den Sinn), aber ich möchte eigentlich in Zukunft nur ungern auf den Komfort von KDEvelop verzichten - Sprich ich will nicht zu jeder Implementierung erst ewig herumlesen, was ich denn so alles dazu linken muß.

    Wie bindet Ihr Tool - Klassen, die Ihr wiederverwendet in bestehende Projekte ein?

    0
  • T

    mhh, ich scheine wohl nicht drum herum zu kommen mich selber mal eingehender damit zu beschäftigen:).
    Wenn dieser Artikel : http://seul.org/docs/autotut/ recht hat, dann muß jedes Src - Subdirectory auch ein eigenes Makefile.am haben, wenn man mit automake &co. arbeiten will.
    Ich kann den Link nur empfehlen, da ich jetzt zumindest eine ungefähre Vorstellung habe, was passiert, wenn ich wild auf den Schaltflächen von KDEveleop herumdrücke :D. Ich werde das heute abend gleich mal ausprobieren.

    0
  • T

    Schon ein Stück weiter: Zumindest soweit zu verstehen, das automake ein geniales Tool ist. Leider hält es das nicht davon ab, dass das was ich realisieren will nicht funktioniert :).
    Der Fehler des 1. Postings war übrigens, das die m4 Version nicht zur autoconf - Version gepasst hat(nur am Rande).
    Mein Problem jetzt ist eigentlich eher trivialer Natur. Die Sources , die ich in mehreren Projekten nutzen will liegen in einem Ordner, der in der Hierarchie weiter oben stehen sollte. Aber irgendwie scheint automake ein Problem damit zu haben, wenn ich einen relativen Pfad dorthin angebe:

    SUBDIRS = src ..\..\Reversi

    meint automake das / in der Pfadangabe unzulässig ist.

    Ist das tatsächlich so, oder kann ich das umgehen? Oder muß ich tatsächlich aus diesen Sources seperat aine lib erstellen, die ich zu den anderen Projekten dazu linke?

    Sorry, als VS - verwöhnter, Windows - Benutzer binne ich mit solchen Aufgaben, die sich dort nie stellen, doch ein bisschen überfordert.

    0
  • R

    Also was jetzt? \ oder /?

    0
  • S

    Ringding schrieb:

    Also was jetzt? \ oder /?

    Hast du schon mal ein UNIX Pfad gesehen, der \ für die Trennung der Verzeichnisse benutzt wird? Ich nicht.

    0
  • R

    Nein, daher wundert es mich auch nicht, dass es Probleme gibt, wenn er ..\..\Reversi schreibt. Aber in diesem Fall kann sich automake nicht über / aufregen, weil gar keins da ist.

    0
  • T

    Bahhh, das kommt davon, wenn man nicht kopiert 🙂

    natürlich ../../

    Sorry - das ist wohl der Rückfall in alte Windows Gewohnheiten. Demzufolge auch / in der Fehlermeldung.
    Ihr stützt euch aber auch sofort drauf wie die Geier :). Die Problematik und die Frage bleibt aber ja wohl die selbe : unterstützt automake bei der Angabe von SUBDIRS die Angabe von Pfaden, die in der Verzeichnishierarchie relativ oberhalb des "Haupt"-Makefiles liegen.

    0
  • R

    Man muss halt mal die offensichtlichen Ursachen ausschließen, wenn du nicht sorgfältig genug warst.

    automake funktioniert so lange gut, solange man es genau so benützt wie es gedacht ist. Irgendwelche Spezialwünsche, und du hast Scherereien. Vielleicht könntest du das ja mit einem symbolischen Link erreichen.

    0
  • F

    Hi,

    du könntest auch die gemeinsamgenuzten *.cpp dateien ja einmal als object files
    übersetzen und die dann in den entsprechenden Projecten dazu linken.

    Oder wie gesagt das ganze per symlink.

    gruß
    firefly

    0
  • N

    TheBigW: Mal ganz was anderes; hast Du Dir uU schonmal scons angeschaut? Ich setze das gerade zum ersten Mal für ein RealWorld-Projekt ein, und bis jetzt gefällt es mir sehr gut. 👍

    0
Anmelden zum Antworten