That's right .. it was just a slight modification of gcc tool at the
point I've created it and the detection is like:
env['CC'] =env.Detect(compilers) or'clang'
In gcc I see now:
compilers = ['gcc', 'cc']
...
if 'CC' not in env:
env['CC'] = env.Detect(compilers) or compilers[0]
so both tools work similarly, using hard-coded compiler in case no
compiler is found with Detect().
W dniu 06.01.2015 o 05:03, Bill Deegan pisze:
Looks like your clang tool is not properly detecting that the tool is
not there and indicating that..
On Mon, Jan 5, 2015 at 5:56 PM, Paweł Tomulik <[email protected]
<mailto:[email protected]>> wrote:
Thanks Bill,
I took a look at manpage and user docs. It says how we may
"specify tools" and not much more.
As I understand, this allows us to specify what tools are
**required** for our project (sorry, this is not clearly stated by
docs so I may be wrong here). This doesn't seem to provide a way
to define **alternatives** for a tool (under a given platform).
Let's take an example:
# SConstruct
# Let's say I prefer clang but allow gcc (or reverse)
env = Environment(tools = [])
env.Tool('gnulink')
env.Tool('gcc')
env.Tool('clang')
env.Program('hello.c')
/* hello.c */
int main() { return 0; }
Now, some real test:
1. Installed gcc, but not clang:
ptomulik@debian:~/test1$ scons
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
clang -o hello.o -c hello.c
sh: 1: clang: not found
scons: *** [hello.o] Error 127
scons: building terminated because of errors.
2. Installed clang but not gcc:
ptomulik@debian:~/test1$ scons
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
clang -o hello.o -c hello.c
clang -o hello hello.o
scons: done building targets.
3. Installed both gcc and clang
ptomulik@debian:~/test1$ scons
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
clang -o hello.o -c hello.c
clang -o hello hello.o
scons: done building targets.
ptomulik@debian:~/test1$ scons -v
SCons by Steven Knight et al.:
script: v2.3.1, 2014/03/02 14:18:15, by garyo on lubuntu
engine: v2.3.1, 2014/03/02 14:18:15, by garyo on lubuntu
engine path: ['/usr/lib/scons/SCons']
Copyright (c) 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008,
2009, 2010, 2011, 2012, 2013, 2014 The SCons Foundation
Clearly, this does not work as expected.
The Tool('gcc') always returns None and does not throw exception.
One way, to cimcurvent this is to determine manually what
compilers are available and then provide approptiate argument to
env.Tool(), but will my compiler search work better than the
"internal search" performed by Tool()?
W dniu 06.01.2015 o 01:15, Bill Deegan pisze:
Pawel,
Take a look at Environment() in the Man Page and look at it's
tools argument.
There should also be info in the users guide.
The default behavior when no tools= is specified is supposed to
be reasonable, but developers can always do what they want.
Often I use Environment(tools=[]) and then env.Tool('gcc')... to
be very explicit
-Bill
On Mon, Jan 5, 2015 at 4:13 PM, Paweł Tomulik
<[email protected] <mailto:[email protected]>> wrote:
Well, I thought that there were just defaults for given
platform, for example gcc for Linux (so it used gcc, if it's
installed or fails if it's not, even if other supported
compilers are available)?. Am I wrong?
W dniu 06.01.2015 o 01:08, Bill Deegan pisze:
Pawel,
It's always been possible to set tool preference in the
Environment() creation.
As far as allowing a user to override such via local
settings, that's be up to the project using SCons.
Allowing such by default would likely cause more issues than
it solves as one of the core functional requirements of
SCons is that it enables a reproducible build regardless of
the users environment.
(This is to enable production software builds, as opposed to
open source builds which typically want autoconf like
behavior, which is also core functional requirement for
SCons to enable)
-Bill
On Mon, Jan 5, 2015 at 4:02 PM, Michael Jarvis
<[email protected] <mailto:[email protected]>>
wrote:
Clang can (mostly) emulate gcc, while the reverse is not
true. I would say default to gcc as well.
On Mon, Jan 5, 2015 at 6:00 PM, Bill Deegan
<[email protected]
<mailto:[email protected]>> wrote:
I'd say on linux default to gcc.
If we add clang tools the user can always override
them if they wish to.
-Bill
On Mon, Jan 5, 2015 at 3:58 PM, William Blevins
<[email protected]
<mailto:[email protected]>> wrote:
Im not sure what percentage of linux devs use
clang vs gcc, but my personal experience is gcc
is more widely used.
Yet another gcc user,
William
On Jan 5, 2015 6:51 PM, "Russel Winder"
<[email protected]
<mailto:[email protected]>> wrote:
On Mon, 2015-01-05 at 13:48 +0100, Paweł
Tomulik wrote:
[…]
> I have a project where I just set
construction variables CC=clang and
> CXX=clang++ and it works well (I check
existence of these compilers with
> SConf, so I don't need the Tool machinery
to search for the compiler
> executables).
>
> Some time ago I also wrote these two tools:
>
> https://github.com/ptomulik/scons-tool-clang
> https://github.com/ptomulik/scons-tool-clangpp
>
> but for some (forgotten) reason I don't
use them :)
This may work fine, but if SCons does not
have tools called clang, clang
++, clanglink *AND* detection of clang for
the cc, c++ and link tools,
then SCons has no credible support for Clang.
My real question is whether SCons should
prefer clang over gcc for
Linux.
--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200
<tel:%2B44%2020%207585%202200> voip:
sip:[email protected]
<mailto:sip%[email protected]>
41 Buckmaster Road m: +44 7770 465 077
<tel:%2B44%207770%20465%20077> xmpp:
[email protected]
<mailto:[email protected]>
London SW11 1EN, UK w: www.russel.org.uk
<http://www.russel.org.uk> skype: russel_winder
--
Pawel Tomulik
_______________________________________________
Scons-dev mailing list
[email protected] <mailto:[email protected]>
https://pairlist2.pair.net/mailman/listinfo/scons-dev
_______________________________________________
Scons-dev mailing list
[email protected]
https://pairlist2.pair.net/mailman/listinfo/scons-dev
--
Pawel Tomulik
_______________________________________________
Scons-dev mailing list
[email protected]
https://pairlist2.pair.net/mailman/listinfo/scons-dev
