Autotools build scheitert subdir-objects option in AM_INIT_AUTOMAKE

Ich bin momentan an einem C++ Projekt stützt sich auf Rekursives automake um Sie zu bauen.
Ich will bauen, eine gemeinsame Bibliothek und die Makefile.am im src Verzeichnis der Bibliothek sieht aus wie

# ...

# Library name
lib_LTLIBRARIES = libadapter-@[email protected]

# Sources
libadapter_@MY_API_VERSION@_la_SOURCES = \
    $(top_builddir)/src/sourceA.cpp \
    $(top_builddir)/src/sourceB.cpp

# ...

Seit der version 1.14, automake gibt eine Warnung, wenn die subdir-objects option nicht angegeben ist, in AM_INIT_AUTOMAKE im configure.ac. Doch indem die subdir-objects option scheint zu brechen, den build-Prozess mit make beschweren sich über fehlende .Plo - Dateien. Ich habe bereits gesucht das web für Menschen mit ähnlichen Problemen, aber nicht zu finden, die jeder vernünftige Hinweis darauf, wie das Problem zu beheben ohne änderung des Projekts, um eine nicht-rekursive. Jede Hilfe wird sehr geschätzt.

EDIT:
Tauchen Sie tiefer in das problem, ich habe festgestellt, dass ./configure erstellt ein Verzeichnis wörtlich benannt $(top_builddir) unter dem aktuellen source Verzeichnis, das die Bibliothek enthält alle erforderlichen .Plo Dateien für den Aufbau der Bibliothek. In der Makefile fand ich allerdings, dass die .Plo äquivalente von "meine Bibliothek" Quellen (sourceA.cpp und sourceB.cpp im Beispiel) vorangestellt sind include $(top_builddir)/src/$(DEPDIR)/ und $(top_builddir) eine variable ist definiert als ein relative Pfad (nämlich ../../../src/.deps/). Jetzt wird auch klar, warum make nicht finden können, die .Plo - Dateien, weil es sucht im falschen Verzeichnis. Das sieht wie ein mögliches Duplikat von bug #16375. Irgendwelche workarounds?

EDIT 2:
Graben weiter in das web offenbart zwei weitere threads, die das Thema angehen: #1327 und automake-bug. Eine bekannte Abhilfe scheint zu sein, vorbei die --disable-dependency-tracking option ./configure. Zumindest für mich, es funktioniert.

Verwenden Sie relative Pfadangaben für die QUELLEN?
FWIW, ich bekomme diese Meldung auch mit automake 1.14 (nicht-rekursive bauen, keine relativen Pfade). Derzeit ist meine Strategie um die Warnung zu ignorieren, bis ich einen Weg finden, nicht Filmfehler die bauen. Scheint zu bauen OK (bis jetzt...).
Interessant. Verwenden Sie ACLOCAL_AMFLAGS in top-level-Makefile.bin? Was ist mit den AM_INIT_AUTOMAKE Optionen?
Ich benutze ACLOCAL_AMFLAGS nur um das makro Pfad (-I ...). Die AM_INIT_AUTOMAKE Optionen werden durch AUTOMAKE_OPTIONS: 1.11 foreign. Das ist es.
OTOH, vielleicht bin ich nicht relative Pfade zu verwenden. Vielleicht habe ich zu wechseln top_srcdir zu abs_top_srcdir und top_builddir zu abs_top_builddir. Hmm...

InformationsquelleAutor Marcel | 2014-02-06

  1. 5

    Aus der automake-1.14.1 NEWS Datei:

    The next major Automake version (2.0) will unconditionally activate
the 'subdir-objects' option.  In order to smooth out the transition,
we now give a warning (in the category 'unsupported') whenever a
source file is present in a subdirectory but the 'subdir-object' is
not enabled.  For example, the following usage will trigger such a
warning:

        bin_PROGRAMS = sub/foo
        sub_foo_SOURCES = sub/main.c sub/bar.c

    So, in Vorbereitung auf diese, müssen Sie subdir-objects als eine der Optionen in AM_INIT_AUTOMAKE, wenn Sie Unterverzeichnisse in 'object' - Namen wie oben beschrieben. Ist diese option 'on' standardmäßig in 2.0.

    Wenn Sie könnte die Makefile.am für das Verzeichnis, das schlägt fehl, er könnte eine Ahnung, warum die relative Verzeichnisse nicht passen.

    Ok, es gibt ein paar Dinge über dieses Makefile.am. Erstens, es gibt Möglichkeiten, richtig version eine libtool-Bibliothek, und @MY_API_VERSION@ Substitutionen sind nicht der Weg zu gehen. Sie könnte die form einer numerischen Zeichenkette beispielsweise in configure.ac, gefolgt von AC_SUBST(MY_API_VERSION).

    In Makefile.am : libadapter_la_LDFLAGS = -release $(MY_API_VERSION) werden diese Informationen in der libadapter.la libtool-meta-Datei.

    Für ernst Versionskontrolle, wo interface-Kompatibilität, Revisionen, Binär-Kompatibilität, etc., wünschenswert sind, können Sie einen Blick auf die libtool Verweis auf Versionierung. Wichtige system-Bibliotheken, vor allem die GNOME/GTK (achten Sie auf Ihre configure.ac - Dateien!), gehen all-out auf dieses Zeug. Ich sicherlich nicht, es sei denn, ich überlege mir etwas loslassen in die wildnis. Ich finde es immer noch verwirrend.

    Weglassen @MY_API_VERSION@ können Sie auch den stick mit libadapter_la_SOURCES. Aber die Quell-Dateien nicht gefunden werden, die relativ zu jedem builddir Weg, das war vielleicht die Quelle der .Plo Datei Problem. Die builddir Variablen beschreiben, wo die gebaut Komponenten gefunden werden - Sie können auch die build-out-of-tree, und das ist ein guter test, um zu sehen, ob Ihr automake-setup ist robust. Einige Pakete fördern, z.B., gehen Sie auf die Oberseite des Pakets, erstellen Sie ein Verzeichnis namens build oder my_build oder was auch immer passt:

    cd my_build; ../configure <options>; make

    Dem Paket, es ist Quellcode-Baum und rekursive Verzeichnisse werden allein gelassen, alles wird gebaut, unter der my_build Verzeichnis und die Unterverzeichnisse spiegeln die von den source-tree, nur Sie werden voll integrierte Objekte, Bibliotheken, ausführbare Dateien, etc. make install sollte auch perfekt funktionieren unter Verwendung der generierten my_build/Makefile.

    Aber wieder an den Punkt - diese Quellcode-Dateien sind im Vergleich zu den $(srcdir) - Verzeichnis, das entspricht der aktuellen (rekursive) Makefile.am's-Verzeichnis. Die verschiedenen builddir und srcdir Variablen beschrieben werden hier.

    Wenn Ihr src - Verzeichnis befindet sich unter dem Verzeichnis der obersten Ebene, den Sie verwenden könnten: "$(top_srcdir)/src/sourceA.cpp" - beachten Sie, dass "$(srcdir)/src/sourceA.cpp" wäre falsch, wie es wäre, wie die Angabe "$(top_srcdir)/src/src/sourceA.cpp" in diesem Fall.

    Du könnte Verwendung "$(srcdir)/sourceA.cpp", aber dieses directory ist implizit sowieso. Alles, was Sie brauchen, ist:

    libadapter_la_SOURCES = sourceA.cpp sourceB.cpp

    Ist es auch vollkommen akzeptabel, um alle header-Dateien in die src Verzeichnis libadapter im SOURCES Liste. Eine änderung der header neu erstellen, was erforderlich ist.

    Sowieso, ich wollte nicht schreiben das viel, aber ich weiß, wie frustrierend es ist, klare Informationen über die autotools. Die Autotools-Mythbuster bietet hervorragende "walk-through" - tutorials, und bleibt sehr aktuell.

    Ich war bereits bewusst diesen Ausschnitt aus dem automake NEWS - Datei, aber von dem was ich verstehe, automake sollte reibungslos funktionieren, wenn die subdir-objects option wird einfach Hinzugefügt AM_INIT_AUTOMAKE im configure.ac - egal, ob relative oder absolute Pfade verwendet werden Makefile.am. Bitte korrigieren Sie mich, wenn ich falsch Liege.
    Ich habe versucht, die Probleme anzusprechen, die in Ihrem Makefile.am. Ich hoffe, Sie finden es hilfreich.
    Vielen Dank für diese erschöpfende Antwort. Ich sehe den Unterschied zwischen top_srcdir und top_builddir aber ich verstehe nicht, warum der Austausch der letzteren durch die erstere sollte keinen Unterschied machen, für in-tree baut, die ist, was ich im moment tun. Auch, weglassen der MY_API_VERSION sollte nicht dazu beitragen, die Lösung des Problems. In der Zwischenzeit, ich glaube ich habe den Grund gefunden für die fehlerhafte bauen, siehe meine aktuelle Frage.
    Ja, das habe ich, aber ohne Wirkung, der Fehler bleibt.

    InformationsquelleAutor Brett Hale

Schreibe einen Kommentar