This is the mail archive of the mailing list for the newlib project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] link headers if possible

At Tue, 22 Jan 2008 10:56:48 +0000,
Andrew STUBBS wrote:
> Neal H. Walfield wrote:
> > This patch removes one scenario where I've had to run make clean to
> > make the build system recognize some changes that I've made in the
> > source tree.  Specifically, it tries first to link header files to
> > targ-include and only falls back to copying them if that fails.
> That won't give any benefit to platforms where links don't work. MinGW 
> springs to mind.

Yes, on platforms where there are no symlinks, this should be no worse
than the status quo.

> How about something more like this?
>     HFILES := $(shell cd $(WHEREEVER) && find . ! -type d -name '*.h')
>     LOCALHFILES := $(addprefix targ-include/,$(HFILES))
>     targ-include/% : $(WHEREEVER)/%
> 	   $(INSTALL) -D -p $< $@
>     all: $(LOCALHFILES)
> This will probably only work with GNU make and only when find is 
> available, but those are probably requirements already. Make now treats 
> the individual header files as dependencies and updates them as required.

This apporach would be fine but unless I misunderstand your code, your
code does not use the same selection criteria for choosing the headers
to install.  For instance, there is a lock.h in
libc/include/sys/lock.h and another in libc/sys/linux/sys/lock.h.
When configuring for GNU/Linux, the latter is installed in
targ-include, other the more generic one is used.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]