apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@ebuilt.com>
Subject Re: cvs commit: apr/test Makefile.in
Date Tue, 01 May 2001 23:29:14 GMT
> Basically, the LINK macro would use LOCAL_LIBS and ALL_LIBS. The Makefile
> would just need to set LOCAL_LIBS. It may have been that I did the "set"
> after including rules.mk, so it didn't "take".

I don't think that would make any difference since the variables aren't
evaluated until they are used.  That's why I can't so something like

   LIBS = locallib1.a $(LIBS)

The problem with including things like ALL_LIBS in the LINK command
itself is that it becomes hard to get the order right with overrides.

We should really have separate LINK macros for linking a library versus
linking a program, and we should be picking up program-specific make
variables instead of assuming they are all the same per directory.  Like

   testname_LDFLAGS = -dynamic
   testname_LDADD = ../libapr.a
   testname_DEPENDENCIES = ../libapr.a

   testnames: $(testnames_OBJECTS) $(testnames_DEPENDENCIES)
	@rm -f testnames
	$(LINK) $(testnames_LDFLAGS) $(testnames_OBJECTS) $(testnames_LDADD) $(LIBS)

In truth, what we'll end up with will be very much like automake except
that our stuff doesn't assume the Gnu tools are installed.

Does anyone know if nested variable refs are portable?  Like

$(PROGRAMS): $($@_OBJECTS) $($@_DEPENDENCIES)
	@rm -f $@
	$(LINK) $($@_LDFLAGS) $($@_OBJECTS) $($@_LDADD) $(LIBS)


....Roy


Mime
View raw message