[linux-l] Re: Makefile

Steffen Dettmer steffen at dett.de
Di Dez 3 01:04:59 CET 2002


* Rainer Flicker wrote on Mon, Dec 02, 2002 at 22:36 +0100:
> > Da hab ich mich noch nicht "rangetraut", hatte zuviele Probleme
> > mit diesem libtool bei 3rd party stuff.
>                           ^^^^^^^^^
> Compiler / Linker?

nee, libs, also libodc++ oder sowas, die libtool verwenden. make
libtool z.B. geht meistens schief, bzw. klappt das, aber das
libtool funktioniert dann nicht etc. Na ja, ich kann es aber
nicht bedienen.

> > Na ja, in den Depenencies der Sourcen steht dann z.B.
> > #include <subdir/hallo.h>

> Wenn die Headerfiles innerhalb deines package liegen, dann
> müsste es
> #include "subdir/hallo.h"
>          ^^              ^^
> lauten.

Ja, subdir ist ja nicht innerhalb meines Packages (und selbst
dann schreibe ich meistens <...>), aber das ändert auch nichts
(hab beides probiert). subdir liegt in ../other_package bei
--with-other_package. Wenn das subdir in der gleichen Package
liegt, sind die depenendcies ja richtig!

> > über ../../sonstwas/ wird das dann z.B. bei gcc -E oder -M
> > #include <../../sonstwas/subdir/hallo.h>
> > Nun ist das automake bißchen langweilig bei dependencies. So in
> > etwa: was mit /usr anfängt, ist 'ne System-Dependency, und
> > wandert nicht ins Makefile. 
> Das Makefile wird allerdings erst von configure aus dem
> Makefile.in erzeugt.

Gut, daraus folgt, das das Makefile.in schon falsch ist. Ist aber
auch egal, im make dist hab ich Makefile.in die falsch sind,
damit auch die erzeugten Makefiles (da man in der Dist ja nur
configure aufruft, nicht jedoch automake & co). Und genau das ist
mein Problem. In einer Dist funktioniert autoconf wieder nicht,
weil da M4 Macros verwendet werden, die nicht zu der package
gehören, und ich keine autoconf Macros global installieren
möchte, nur um autoconf sagen zu können. Ich will ja nur ne Dist
bauen, die auch andere Pfade als /usr für's System hat. Ich kann
die Aufzählen, dynamisieren, sonstwas, es soll nur 

make dist && \
tar -x package*tgz && \
cd package* && \
./configure $NEEDED_OPTS && \
make 

klappen, oder mein "make rpm", ohne das ich AUTOMAKE_OPTIONS =
no-dependencies machen muß. Ja, natürlich könnte ich die anderen
Packages nach /usr installieren, aber das ist a) nicht FHS (ich
will /opt), und zweitens für die parallele Entwicklung mehrerer
Packages viel zu aufwendig...

> > holst, dürfte das knallen. Jedenfalls schreibt automake die
> > Abhängigkeiten so (also ../../) in die Makefiles, die dann auch
> > bei make dist eingepackt werden. 

> Bei "make dist" werden keine Makefiles eingepackt, da diese ja
> erst von configure erzeugt werden sollen. 

Sorry, ich meinte natürlich Makefile.in, aber das ist doch aus
dem Kontext klar... Die dependencies selbst stehen sogar jeweils
in .deps oder so. Aber Du weißt ja, was ich meine.

> In einem Makefile.am
> reicht:
> bin_PROGRAMS = pkgtest
> 
> pkgtest_SOURCES = \
>    global.h \
>    main.c
> 
> Dann machst vielleicht:
> > ./configure --with-package=/anderswo/sonstwas
> "--with-package" ist für fremde Pakte, wieso sollte es damit
> Probleme geben.

Weil eben automake die Abhängigkeiten mit in Makefile.in
(bzw. .deps) schreibt (und .deps included). Hab ich doch
geschrieben.

also:

es gibt u.A.:

package1/src/ingenico/de/mein_include.h

und:

package2/src/ingenico/de/test.c

dann mach ich sowas wie:

cd package2
./configure --with-package1=../package1
(erzeugt u.A. CFLAGS="-I../package1/src")

in test.c steht
#include <ingenico/de/mein_include.h>
oder auch
#include "ingenico/de/mein_include.h"

dann steht in den Dependencies sowas wie

test.o: ../package1/src/ingenico/de/mein_include.h

und wird so in die "dist" gepackt. Macht man mit der Dist ein

cd package2-*
./configure --with-package1=/opt/ingenico/package1
(erzeugt u.A. CFLAGS="-I/opt/ingenico/package1/include")

und dann:

make

kommt error:
no rule to make target ../package1/src/ingenico/de/mein_include.h

Weil es natürlich auch in
/opt/ingenico/package1/include/ingenico/de/mein_include.h steht,
der -I ist natürlich korrekt, nur eben die dependencies nicht.

Ist das Problem jetzt gut genug beschrieben? Jemand ne Idee? 

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.




Mehr Informationen über die Mailingliste linux-l