GNU Autoconf - eigene configure-Option?

NetzUnity und Informatik-forum wurden zusammengelegt. Eine entsprechende Ankündigung wird demnächst noch folgen. Für 2025 ist hier einiges geplant! Bei Fragen bitte per DM an Maximilian Rupp wenden.
  • Hallo,

    ich spiele mit dem Gedanken, ein kleines Kommandozeilen-Tool, welches bisher einfach über "make" kompiliert wird, auf eine autoconf/automake - Buildvariante umzustellen.

    Das Programm besteht aus ein paar Source-Dateien (C++) und den dazugehörigen Headers und verwendet ein paar ganz simple Textdateien zur Konfiguration. Bisher ist in der Makefile also einfach ein Befehl beim install-Target dabei, der diese Konfigurationsdateien in ein Unterverzeichnis von /etc kopiert und beim Kompilieren ein Makro auf den kompletten Pfad dieses Verzeichnisses setzt, welches dann zum Öffnen der Dateien verwendet wird.

    Ich will das jetzt eleganter lösen:

    • Benutzer führt ./configure mit einer benutzerdefinierten Option (sowas wie ./configure --prefix=/usr/local --configdir=/bla)
    • Das configure-Skript fügt dann in der generierten config.h eine Präprozessor-Direktive mit diesem Pfad hinzu (#define CONFIGFILE=/bla)
    • make kompiliert das ganze
    • make install kopiert das Programm und die dem Source-Code beiliegenden Default-Konfigurationsdatei in das so angegebene Verzeichnis

    Jetzt bin ich aber als autoconf/automake-Noob relativ ratlos... habe mich durch ein paar Tutorials und die offizielle Dokumentation gequält, aber leider keine Anleitung zu so einem Vorhaben gefunden. Kann mir da einer Tips bzw. einen Link zu so einem Tutorial geben?

    Danke im Vorraus!

  • Ich habe mich mal darangewagt, eine Compileoption zu einem vorhandenen autoconf/automake hinzuzufügen und ich kann nach sehr viel Ärgern und in den Tisch beißen davon nur absolut abraten, wenn du eh noch die Möglichkeit hast, etwas Anderes zu nehmen. Alleine für die Syntax sollte man jemanden erschießen.

    Viele Projekte gehen von autoconf/automake gerade weg, weil es so brainfucked ist. KDE hat z.b. zu cmake gewechselt, das scheint etwas schöner zu sein. Das könntest du dir auch anschauen.

    Dipper dipper dii dipper dii dipper dii duuu

  • In SE/Linux war (zumindest zu meiner Zeit) autoconf/automake Vorgabe, das waren die schmerzhaftesten Programmiererlebnisse meines gar nicht mehr so kurzen Lebens...

    [font=verdana,sans-serif]"An über-programmer is likely to be someone who stares quietly into space and then says 'Hmm. I think I've seen something like this before.'" -- John D. Cock[/font]

    opentu.net - freier, unzensierter Informationsaustausch via IRC-Channel!
    Hilfe und Support in Studienangelegenheiten, gemütliches Beisammensein, von und mit Leuten aus dem Informatik-Forum!

  • Tu dir automake nicht an, das ist reiner Masochismus. Aus eigener Erfahrung kann ich sagen, dass CMake um Längen besser ist (meine Empfehlung deshalb), aber auch ziemlich alle anderen sind eher zu bevorzugen als automake & friends.

    "Egbert B. Gebstadter is the Egbert B. Gebstadter of indirect self-reference." - Egbert B. Gebstadter

  • Danke für die Ratschläge!

    habe in der Zwischenzeit etwas mit autoconf/automake herumgespielt, nach einigen :cuss:-Erlebnissen geht jetzt das simple Kompileren das vorher auch schon gegangen ist...

    werde mir wirklich mal CMake anschauen, schlimmer kanns nicht mehr werden :D

    Verwundert mich nur warum so viel noch immer mit autoconf/automake gearbeitet wird, fast jedes "kleinere" softwarepaket hat halt das obligatorische ./configure && make && make install dabei...

  • Tu dir automake nicht an, das ist reiner Masochismus. Aus eigener Erfahrung kann ich sagen, dass CMake um Längen besser ist (meine Empfehlung deshalb), aber auch ziemlich alle anderen sind eher zu bevorzugen als automake & friends.

    Ich hab gesehen du kuemmerst dich jetzt auch um icon naming scheme in KDE? was machst sonst noch, und bist noch immer bei KDevelop, oder das nicht mehr?

    @automake: naja, auch wenn ich es sehr gern sehen taete, dass die leute davon wegswitchen, ausser eine handvoll "grosse" hab ich noch nciht gesehen, und gibt auch andere grosse, die extra zu automake switchen (Xorg).


  • Verwundert mich nur warum so viel noch immer mit autoconf/automake gearbeitet wird, fast jedes "kleinere" softwarepaket hat halt das obligatorische ./configure && make && make install dabei...

    Das ist halt die macht von quasi-monopolen, es traut sich (teilweise auch zurecht) halt oft keiner, ein kleines unbekannteres make-tool zu verwenden, um keine zusaetzliche dependency zu haben.

  • Wenn du das ganze schon mal fertig verdrahtet hast, dann ist das Hinzufügen einer Option allerdings ziemlich unkompliziert. Ich kann's dir jetzt leider nicht genau sagen, aber eine sehr effiziente Methode, um herauszufinden, was dafür getan werden muss, ist das Nachsehen im SVN-Repository eines bestehenden Projekts, bei dem eine neue Option hinzugekommen ist ;)

  • Ich hab gesehen du kuemmerst dich jetzt auch um icon naming scheme in KDE?


    Jup, gut gesehen. Das wär sonst völlig untergegangen, und zum Wohle aller Icon-Designer und Interoperabilitätsliebhaber muss es halt irgendwer machen. Als vormaliger Lila-Maintainer und in die Materie eingearbeitete Mischung aus Amateur-Icon-Zeichner und Programmierer bin das dann eben ich.

    Zitat

    was machst sonst noch, und bist noch immer bei KDevelop, oder das nicht mehr?


    KDevelop ist irgendwie untergegangen, da hab ich ca. zum Jahreswechsel ein bisschen die Motivation verloren. Dafür mach ich jetzt ein paar Sachen mit Drupal (war diesmal mit einem VCS-Abstraktionsmodul beim Summer of Code dabei), bin jetzt auch Teilzeit-Arbeiten und geh mehr fort :D

    Fragt sich nur noch, wann mal wieder ein Forumstreffen steigt. Ups, offtopic :devil:

    "Egbert B. Gebstadter is the Egbert B. Gebstadter of indirect self-reference." - Egbert B. Gebstadter

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!