On Tue, Jun 2, 2020 at 10:19 AM Paul Smith <psm...@gnu.org> wrote: > On Tue, 2020-06-02 at 08:48 -0400, Sam Kendall wrote: > > > I suggest that > > > a) $HOME/.local/include is effectively added to the > > > include_directories ... > > > > If two users build the same source tree, they will effectively be > > building variants of it, each extending it with her own > > $HOME/.local/include directory. And if one user builds two > > *different* source trees, she will effectively add those same > > extensions to both source trees, even if they were intended only for > > one. > > > > Those are both bad results. I am strongly against this proposal. >
Rereading this ... sorry, Christian; I didn't mean to sound rude. I'm just making a technical argument. I'm not sure I understand the concern here. > > Note that we're talking about default places to search for included > makefiles, only; this isn't related to any locations that compilers or > other tools invoked by make would search. > Understood. But it enables those included makefiles to do arbitrary other things. > GNU make already (as noted in the email) supports global directories > for searching so adding a per-user directory seems logical and not new, > problematic behavior to me. > I've mostly worked in product development organizations with many developers and with several OSes as build targets. I don't want to add another magic (hidden) way that one developer's build can differ from another's -- as in, "hey, my build is broken." "Okay, what's different between your build and mine?" Over the years, the trend I've seen, and encouraged, has been to reduce reliance even on global directories such as /usr/local in favor of files that are in the source tree and so under version control. User-specific include directories seem worse than global directories in this regard. As far as I know, compilers don't provide user-specific include directories; or if they did, I would be horrified if developers on shared projects took advantage of them. And I see make and compilers as being in the same class of tools. --Sam
