On Fri, Jan 16, 2009 at 11:10 AM, Mike Frysinger <vap...@gentoo.org> wrote: > On Friday 16 January 2009 09:21:31 Masatake YAMATO wrote: >> > On Thu, 2009-01-15 at 10:31 -0500, Mike Frysinger wrote: >> > > On Thursday 15 January 2009 01:56:47 Masatake YAMATO wrote: >> > > > --- a/Makefile >> > > > +++ b/Makefile >> > > >> > > not sure we want to encourage "documentation-in-the-build-system". >> > > could you add this stuff to INSTALL instead ? when people think "how >> > > do i build this package", i'd think they'd (or at least they should) >> > > look at the documentation first rather than the build system. >> > >> > True, >> > >> > Yamato, can you please resend as per Mike´s comments ? >> >> Signed-off-by: Masatake YAMATO <yam...@redhat.com> > > patch looks fine ... if Subrata doesnt merge it, i'll get around to it some > point this weekend > >> +To cross compile, override one or more of CC, AR, CROSS_CFLAGS, >> +LOADLIBES, LDFLAGS, & LIB_DIR and be sure to always build from the top >> level. > > unrelated to your change but something we should review in the future ... > CROSS_CFLAGS/LOADLIBES/LIB_DIR look very suspicious (i.e. wrong) to me. > -mike
The only variables that should be used are: For tools: AR CC RANLIB For compilation definitions: CFLAGS LDFLAGS They are standard (minus AR) with input to configure. Here's a working configure.in definition for defining $(AR): dnl Obtained from http://vaja.nectec.or.th/synres/download/HTS/hts_engine_API-1.00/configure.ac AN_MAKEVAR([AR], [AC_PROG_AR]) AN_PROGRAM([ar], [AC_PROG_AR]) AC_DEFUN([AC_PROG_AR], [AC_CHECK_TOOL(AR, ar, :)]) AC_PROG_AR I had to write up a simple implicit rule for turning .o's (implied) into .a's: %.a: $(AR) -rc $@ $^ Questionable variables: CPPFLAGS (shouldn't need this -- hints at an infrastructure problem) Btw, LIB_DIR isn't common; LDLIBS and LOADLIBES are. Example: -bash-3.00$ make -p foo | grep LIB make-3.81: *** No rule to make target `foo'. Stop. .LIBPATTERNS = lib%.so lib%.a $(LINK.o) $^ $(LOADLIBES) $(LDLIBS) -o $@ $(LINK.c) $^ $(LOADLIBES) $(LDLIBS) -o $@ $(LINK.cc) $^ $(LOADLIBES) $(LDLIBS) -o $@ $(LINK.C) $^ $(LOADLIBES) $(LDLIBS) -o $@ $(LINK.cpp) $^ $(LOADLIBES) $(LDLIBS) -o $@ $(LINK.p) $^ $(LOADLIBES) $(LDLIBS) -o $@ $(LINK.f) $^ $(LOADLIBES) $(LDLIBS) -o $@ $(LINK.F) $^ $(LOADLIBES) $(LDLIBS) -o $@ $(LINK.r) $^ $(LOADLIBES) $(LDLIBS) -o $@ $(LINK.s) $^ $(LOADLIBES) $(LDLIBS) -o $@ $(LINK.S) $^ $(LOADLIBES) $(LDLIBS) -o $@ $(LINK.p) $^ $(LOADLIBES) $(LDLIBS) -o $@ $(LINK.cc) $^ $(LOADLIBES) $(LDLIBS) -o $@ $(LINK.r) $^ $(LOADLIBES) $(LDLIBS) -o $@ $(LINK.C) $^ $(LOADLIBES) $(LDLIBS) -o $@ $(LINK.S) $^ $(LOADLIBES) $(LDLIBS) -o $@ $(LINK.c) $^ $(LOADLIBES) $(LDLIBS) -o $@ $(LINK.s) $^ $(LOADLIBES) $(LDLIBS) -o $@ $(LINK.cpp) $^ $(LOADLIBES) $(LDLIBS) -o $@ $(LINK.F) $^ $(LOADLIBES) $(LDLIBS) -o $@ $(LINK.o) $^ $(LOADLIBES) $(LDLIBS) -o $@ $(LINK.f) $^ $(LOADLIBES) $(LDLIBS) -o $@ Apart from that, there's no need. I need to strip the extra variables from my branch as well, because I imposed them back in the day when I didn't know as much as I do now (through painful experience). You can accomplish the same thing with LOADLIBES / LDLIBS that you can with LDFLAGS by hardcoding libraries, but that's really a bad idea anyhow, and anyone that does that deserves to be slapped for poorly engineering a solution ;p. Cheers, -Garrett ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Ltp-list mailing list Ltp-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ltp-list
