automake
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: performing pre-build shell commands with automake


From: John Calcote
Subject: Re: performing pre-build shell commands with automake
Date: Sun, 20 Jun 2010 16:36:36 -0600
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5

On 6/20/2010 3:05 PM, Wesley Smith wrote:
> libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../..
> -I/usr/include/lua5.1 -I/usr/include/cairo -I/usr/include/directfb
> -I/usr/include/freetype2 -g -O2 -MT lcairo.lo -MD -MP -MF
> .deps/lcairo.Tpo -c src/lcairo.c  -fPIC -DPIC -o .libs/lcairo.o
>
> libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../..
> -I/usr/include/lua5.1 -I/usr/include/cairo -I/usr/include/directfb
> -I/usr/include/freetype2 -g -O2 -MT lcairo.lo -MD -MP -MF
> .deps/lcairo.Tpo -c src/lcairo.c -o lcairo.o >/dev/null 2>&1
>   
> There are 2 issues I see:
> 1) Why would the Makefile.am below produce 2 commands compiling the
> same source file into 2 different directories?
>   

The two libtool commands are not exactly alike. The first command
generates position-independent code (PIC) to be used in your libtool
shared library. That's why the object file is placed in the .libs
directory. The second line doesn't use the -fPIC and -DPIC options. This
version of the object file is used in the traditional archive (static
library). The double compile comes from the use of Libtool. However, if
you don't use Libtool, you'll only get static libraries.

> 2) One of those builds commands actually puts lcairo.o in the same
> directory as the Makefile, so I would assume that the rule lcairo.o
> would correspond to this step.
>   

Automake is a little too smart for us here. It won't generate a rule to
build a libtool object if you've already written one - even if it's only
a dependency rule (no commands). To fix this, place the dependency on
the source file, not on the object:

src/lcairo.c : resource.qt

I tested this and it works - here's my test code:

lib_LTLIBRARIES = libfoo.la

libfoo_la_SOURCES = src/foo.c

resource.qt:
        touch TESTING

src/foo.c: resource.qt

And here's the result of running make in the Makefile.am directory:

$ make
touch TESTING
/bin/sh ../libtool  --tag=CC   --mode=compile gcc -DPACKAGE_NAME=\"foo\"
-DPACKAGE_TARNAME=\"foo\" -DPACKAGE_VERSION=\"1.0\"
-DPACKAGE_STRING=\"foo\ 1.0\" -DPACKAGE_BUGREPORT=\"\"
-DPACKAGE_URL=\"\" -DPACKAGE=\"foo\" -DVERSION=\"1.0\" -DSTDC_HEADERS=1
-DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1
-DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1
-DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1
-DLT_OBJDIR=\".libs/\" -I.     -g -O2 -MT foo.lo -MD -MP -MF
.deps/foo.Tpo -c -o foo.lo `test -f 'src/foo.c' || echo './'`src/foo.c
libtool: compile:  gcc -DPACKAGE_NAME=\"foo\" -DPACKAGE_TARNAME=\"foo\"
-DPACKAGE_VERSION=\"1.0\" "-DPACKAGE_STRING=\"foo 1.0\""
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE=\"foo\"
-DVERSION=\"1.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
-DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
-DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
-DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1
-DLT_OBJDIR=\".libs/\" -I. -g -O2 -MT foo.lo -MD -MP -MF .deps/foo.Tpo
-c src/foo.c  -fPIC -DPIC -o .libs/foo.o
libtool: compile:  gcc -DPACKAGE_NAME=\"foo\" -DPACKAGE_TARNAME=\"foo\"
-DPACKAGE_VERSION=\"1.0\" "-DPACKAGE_STRING=\"foo 1.0\""
-DPACKAGE_BUGREPORT=\"\" -DPACKAGE_URL=\"\" -DPACKAGE=\"foo\"
-DVERSION=\"1.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
-DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
-DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
-DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1
-DLT_OBJDIR=\".libs/\" -I. -g -O2 -MT foo.lo -MD -MP -MF .deps/foo.Tpo
-c src/foo.c -o foo.o >/dev/null 2>&1
mv -f .deps/foo.Tpo .deps/foo.Plo
/bin/sh ../libtool --tag=CC   --mode=link gcc  -g -O2   -o libfoo.la
-rpath /usr/local/lib foo.lo
libtool: link: gcc -shared  .libs/foo.o      -Wl,-soname -Wl,libfoo.so.0
-o .libs/libfoo.so.0.0.0
libtool: link: (cd ".libs" && rm -f "libfoo.so.0" && ln -s
"libfoo.so.0.0.0" "libfoo.so.0")
libtool: link: (cd ".libs" && rm -f "libfoo.so" && ln -s
"libfoo.so.0.0.0" "libfoo.so")
libtool: link: ar cru .libs/libfoo.a  foo.o
libtool: link: ranlib .libs/libfoo.a
libtool: link: ( cd ".libs" && rm -f "libfoo.la" && ln -s "../libfoo.la"
"libfoo.la" )
$

I don't know how QT resources are used by source code, but this may be
the more correct way to place the dependency anyway. If QT resources are
somehow "included" in the c sources, then this dependency is more
accurate. If they're just linked into the final library, then the
dependency should be placed between the library and the resource.

John



reply via email to

[Prev in Thread] Current Thread [Next in Thread]