unfortunately, your toolchain flag handling is pretty wrong in general.  here 
is my quick look over, but i wont be doing in depth review until these obvious 
failures are fixed.  i'm also going to assume we require GNU make (this is 
fine, but it tailors my response below).

LDFLAGS is never for libraries, that is what LDLIBS is for.  abusing LDFLAGS 
like this often leads to link failures in semi-common configurations (like 
static).

LOADLIBES should be for internalltp libs and leave LDLIBS for system libs like 
-lpthread and -lm.  and as such, any linking steps have to be "$(LOADLIBES) 
$(LDLIBS)".

uncontrollable output suppression is absolutely not OK.  take a page from the 
kernel and key off of V.  so the rules would look like:
ifeq ($(V),1)
Q =
E = @:
else
Q = @
E = @echo
endif
somerule:
        $(E) "CC  $@"
        $(Q)$(CC) .....

uncontrollable warnings are not OK, especially considering it is trivial to 
allow people to control it:
WFLAGS ?= -Wall -W
also, not all warnings are valid for C and vice versa for C++, so it should 
be:
WCFLAGS ?= -Wall -W
WCXXFLAGS ?= -Wall -W

your %.c rule should look like:
$(CC) $(CFLAGS) $(CPPFLAGS) $(WCFLAGS) -c $< -o $@

i dont know why you've hardcoded the -I$(topdir)/include here but nowhere 
else.  would make more sense to force a prefix to CPPFLAGS:
CPPFLAGS := -I$(topdir)/include $(CPPFLAGS)

CPPFLAGS are the preprocessor flags, not the C++ compiler flags.  so the %.cpp 
rule should look like:
$(CXX) $(CXXFLAGS) $(CPPFLAGS) $(WCXXFLAGS) -c $< -o $@

your default linker rule is missing CFLAGS -- these often contain ABI flags 
which are required at link time as well.  and you should use LD, not CC, and 
the output should be "LD", not "LN".

your "binaries from C" and "binaries from C++" has the order all wrong.  flags 
always come before sources:
$(CC) ...flags... $^ ...libs... -o $@

the %.a target is missing RANLIB

the SUBDIRS_INSTALL_MANGLED looks like it uses foreach when patsubst (or 
something even simpler) should work fine ?  also, rather than picking some 
crazy value, do something somewhat common and simply append "_install".  it'll 
look a lot less weird when compiling and people see this 4242424242 business 
in the make failure output.

why are you using LTP_CUR_DIR ?  why not just use BCURDIR which GNU make sets 
up for you.

why do "cd ... && $(MAKE) ..." ?  is "$(MAKE) -C ..." broken or something ?
-mike

Attachment: signature.asc
Description: This is a digitally signed message part.

------------------------------------------------------------------------------
_______________________________________________
Ltp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list

Reply via email to