From: Steven Knight (knight_at_[hidden])
Date: 2003-03-06 13:23:57
> > FWIW:
> > Yes, this is the norm for a lot of projects on case-sensitive systems
> > (Linux/UNIX/POSIX), so SCons chooses between the C and C++ compilers for
> > a given .c or .C source file like you indicate above.
> > Of course, there's no real distinction between .c and .C on
> > case-insensitive systems like Win32, so on those, SCons assumes both
> > want to use the C compiler. C++ users have to use .cpp or .cc or .cxx
> > or their upper-case counterparts.
> Why? Win32 may be case-insensitive, but it *IS* case-aware. You can
> continue to make the distinction between .c and .C here, the only
> restriction is that it will be impossible to have foo.c and foo.C in the
> same directory (which would be a bad idea in any event, and not likely to
> happen in real projects). You'd only have to take the approach you have
> on systems that are not case-aware.
What you describe can work, sure. I'm simply pointing out that it's not
the observed behavioral norm. We're not trying to get people to change
their behaviors, just trying to supply a reasonable (and modifiable)
default that fits the way they already work with a minimum of hassle.
> > The different behaviors make for a little more explanation in the
> > documentation, but seem to match most closely people's default
> > expectations for their operating system(s).
> > IIRC, we chose these rules for SCons because they match the behavior of
> > GNU Make (among other de facto standards).
> Well, gcc for one behaves as I describe above, so I'm a little surprised
> that GNU Make differs?
> There are issues with native tools, however, which are not likely to make
> a distinction in this regard. For instance, cl fails with the same test I
> tried for gcc, assuming C compilation for .C files.
Maybe I misremembered this. I thought it was because we were following
GNU make, but it could be because of other tools, too.
I can report that we haven't had a lot of complaints since adopting
the rules I described, which I hope means we have a contented user
community, not a non-existent one... :-)
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk