Date: Fri, 20 Nov 2015 00:02:07 -0500 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: Support for out-of-tree build On Thu, Nov 19, 2015 at 11:09:55PM -0500, Rich Felker wrote: > On Thu, Nov 19, 2015 at 12:22:09AM +0000, Petr Hosek wrote: > > > > clean: > > > > - rm -f crt/*.o > > > > + rm -f $(objdir)/crt/*.o > > > > rm -f $(OBJS) > > > > rm -f $(LOBJS) > > > > rm -f $(ALL_LIBS) lib/*.[ao] lib/*.so > > > > > > This can probably just be rm -rf obj, but perhaps we should wait to > > > make that change. And seeing this, I'm mildly in favor of hard-coding > > > obj/ (everywhere) rather than using $(objdir)/ simply because the > > > latter is really dangerous if you override it on the command line with > > > an unwanted setting (like make clean objdir=/). > > > > That's why I avoided using rm -rf $(objdir). I can imagine the use case for > > setting $(objdir) to a different location, changing this to make it > > hard-coded wouldn't be a problem if you prefer. > > Did you mean "can't imagine a use"? To me this looks roughly like a > "second level of out-of-tree support" that's probably not useful, and > could be error-prone e.g. if somebody tries to get clever and use > objdir=., or could be dangerous (objdir=). I think it's best just to > hard-code it. > > [...] > > > +test -f Makefile || ln -sf $srcdir/Makefile . > > Is there a reason you do it this way rather than checking for > srcdir=.? The reason I ask is that existence of a stray makefile > that's not a symlink to the musl makefile should probably be an error > here rather than silently ignored. But maybe there are more things to > consider.. Additional thought: can't we just ln -s $srcdir/src $srcdir/crt . in configure and never have to bother with $(srcdir) in the makefiles? That seems like another big benefit we can get out of putting all the generated files in obj/ (and lib/). Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.