[Bluez-devel] Makefile.am dependency problem

Brad Midgley

author

2005-10-26 22:05 UTC #0 lore raw

Hi

I noticed a strange dependency problem... it's common in bluez where a library is used. Header file changes don't force a recompile:

bmidgley@jag:/usr/src/bluez/utils/common$ make
make: Nothing to be done for `all'.
bmidgley@jag:/usr/src/bluez/utils/common$ touch textfile.h
bmidgley@jag:/usr/src/bluez/utils/common$ make
make: Nothing to be done for `all'.
bmidgley@jag:/usr/src/bluez/utils/common$ touch textfile.c
bmidgley@jag:/usr/src/bluez/utils/common$ make
gcc -DHAVE_CONFIG_H -I. -I. -I..     -Wall -O2 -c textfile.c
rm -f libtextfile.a
ar cru libtextfile.a textfile.o
ranlib libtextfile.a
/bin/sh ../libtool --tag=CC --mode=link gcc  -Wall -O2   -o
test_textfile  test_textfile.o libtextfile.a
gcc -Wall -O2 -o test_textfile test_textfile.o  libtextfile.a

Makefile.am has a line that mentions textfile.h:

libtextfile_a_SOURCES = textfile.h textfile.c

but that doesn't seem to be enough.

In btsco/sbc, the problem is similar, except that the .a is rebuilt (when its .o object really needs to be rebuilt too):

bmidgley@jag:/usr/src/btsco/sbc$ touch sbc.h
bmidgley@jag:/usr/src/btsco/sbc$ make
rm -f libsbc.a
ar cru libsbc.a sbc.o
ranlib libsbc.a
gcc  -DUSE_FIXED  -Wall -O2   -o sbcdec  sbcdec.o libsbc.a -lasound -lm
-ldl -lpthread -lbluetooth
gcc  -DUSE_FIXED  -Wall -O2   -o sbcenc  sbcenc.o libsbc.a -lasound -lm
-ldl -lpthread -lbluetooth
bmidgley@jag:/usr/src/btsco/sbc$ touch sbc.c
bmidgley@jag:/usr/src/btsco/sbc$ make
gcc -DHAVE_CONFIG_H -I. -I. -I..     -DUSE_FIXED  -Wall -O2 -c `test -f
'sbc.c' || echo './'`sbc.c
rm -f libsbc.a
ar cru libsbc.a sbc.o
ranlib libsbc.a
gcc  -DUSE_FIXED  -Wall -O2   -o sbcdec  sbcdec.o libsbc.a -lasound -lm
-ldl -lpthread -lbluetooth
gcc  -DUSE_FIXED  -Wall -O2   -o sbcenc  sbcenc.o libsbc.a -lasound -lm
-ldl -lpthread -lbluetooth

Brad

-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Marcel Holtmann

maintainer

2005-10-26 22:13 UTC #1 lore raw

Hi Brad,

Quoted 18 lines

I noticed a strange dependency problem... it's common in bluez where a library is used. Header file changes don't force a recompile:

bmidgley@jag:/usr/src/bluez/utils/common$ make
make: Nothing to be done for `all'.
bmidgley@jag:/usr/src/bluez/utils/common$ touch textfile.h
bmidgley@jag:/usr/src/bluez/utils/common$ make
make: Nothing to be done for `all'.
bmidgley@jag:/usr/src/bluez/utils/common$ touch textfile.c
bmidgley@jag:/usr/src/bluez/utils/common$ make
gcc -DHAVE_CONFIG_H -I. -I. -I..     -Wall -O2 -c textfile.c
rm -f libtextfile.a
ar cru libtextfile.a textfile.o
ranlib libtextfile.a
/bin/sh ../libtool --tag=CC --mode=link gcc  -Wall -O2   -o
test_textfile  test_textfile.o libtextfile.a
gcc -Wall -O2 -o test_textfile test_textfile.o  libtextfile.a

Quoted 5 lines

Makefile.am has a line that mentions textfile.h:
libtextfile_a_SOURCES = textfile.h textfile.c
but that doesn't seem to be enough.

look at the bootstrap file. I forced this behavior.

Regards

Marcel

-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Brad Midgley

author

2005-10-27 03:09 UTC #2 lore raw

Marcel

Quoted 4 lines

Quoted 2 lines
I noticed a strange dependency problem... it's common in bluez where a library is used. Header file changes don't force a recompile:
look at the bootstrap file. I forced this behavior.

The principle of "least surprise" would suggest that 'make' always rebuilds everything as necessary. At least I would do that in my project if I could figure out how to do it in the autosplat stuff.

Brad

-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Marcel Holtmann

maintainer

2005-10-27 08:07 UTC #3 lore raw

Hi Brad,

Quoted 8 lines

Quoted 4 lines
Quoted 2 lines
I noticed a strange dependency problem... it's common in bluez where a library is used. Header file changes don't force a recompile:
look at the bootstrap file. I forced this behavior.
The principle of "least surprise" would suggest that 'make' always rebuilds everything as necessary. At least I would do that in my project if I could figure out how to do it in the autosplat stuff.

I changed it in the BlueZ CVS to give it a try again. I can't remember why I disabled it, but there was a reason for it. You might wanna take a look at bootstrap and bootstrap-configure now.

Regards

Marcel

-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course Free Certification Exam for All Training Attendees Through End of 2005 Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel