[Scons-dev] Clang support
Paweł Tomulik
ptomulik at meil.pw.edu.pl
Tue Jan 6 03:56:41 EST 2015
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 <ptomulik at meil.pw.edu.pl
> <mailto:ptomulik at meil.pw.edu.pl>> 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 at 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 at 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 at 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 at 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
>> <ptomulik at meil.pw.edu.pl <mailto:ptomulik at meil.pw.edu.pl>> 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
>>> <mjarvis.tx.08 at gmail.com <mailto:mjarvis.tx.08 at gmail.com>>
>>> 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
>>> <bill at baddogconsulting.com
>>> <mailto:bill at baddogconsulting.com>> 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
>>> <wblevins001 at gmail.com
>>> <mailto:wblevins001 at gmail.com>> 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"
>>> <russel at winder.org.uk
>>> <mailto:russel at winder.org.uk>> 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:russel.winder at ekiga.net
>>> <mailto:sip%3Arussel.winder at ekiga.net>
>>> 41 Buckmaster Road m: +44 7770 465 077
>>> <tel:%2B44%207770%20465%20077> xmpp:
>>> russel at winder.org.uk
>>> <mailto:russel at winder.org.uk>
>>> London SW11 1EN, UK w: www.russel.org.uk
>>> <http://www.russel.org.uk> skype: russel_winder
>>>
>
> --
> Pawel Tomulik
>
>
> _______________________________________________
> Scons-dev mailing list
> Scons-dev at scons.org <mailto:Scons-dev at scons.org>
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
>
>
>
>
> _______________________________________________
> Scons-dev mailing list
> Scons-dev at scons.org
> https://pairlist2.pair.net/mailman/listinfo/scons-dev
--
Pawel Tomulik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist2.pair.net/pipermail/scons-dev/attachments/20150106/ca5a7d90/attachment-0001.html>
More information about the Scons-dev
mailing list