Login | Register
My pages Projects Community openCollabNet

Discussions > SCons Development (OBSOLETE) > REVIEW: use smart C/C++ linking in the Intel tool chain (Dmitry Girgorenko and Gary Oberbrunner)

Project highlights:

14 Nov 2017: Release 3.0.1 is now available at the download page.

18 Sep 2017: Release 3.0.0 is now available at the download page.

03 Nov 2016: Release 2.5.1 is now available at the download page.

scons
Discussion topic

Hide all messages in topic

All messages in topic

Re: [scons-dev] Suggestion for testing WAS: REVIEW: use smart C/C++ linking in the Intel tool chain (Dmitry Girgorenko and Gary Oberbrunner)

Author garyo
Full name Gary Oberbrunner
Date 2007-03-07 06:36:04 PST
Message Hi guys --

Steven Knight wrote:
> We do use stubs in a lot of the test scripts, and have lately been trying
> to move the scripts in general towards cleanly separating stubbed scripts
> from ones that still use the live tools.
>
> You usually want some ability to still live tools as a sanity check,

Yup, I even thought about it in this case; you could just check that LINK is
still smart_link after the intelc tool runs. But it's a better end-to-end
check that nothing *else* is wrong to actually compile and link a C++ program.
 In theory could could run both tests; the LINK value test to make sure the
bug doesn't reappear, and the end-to-end one to make sure linking C++ progs
works as intended no matter what else has changed. But that seemed like more
work than necessary, at least to me.

-- Gary

Re: [scons-dev] Suggestion for testing WAS: REVIEW: use smart C/C++ linking in the Intel tool chain (Dmitry Girgorenko and Gary Oberbrunner)

Author stevenknight
Full name Steven Knight
Date 2007-03-07 05:24:09 PST
Message Hi Morten--

> Just a thought or friendly suggestion!
>
> I am by no means confident with the SCons test suite, but still I would
> like to provide a suggestion.
>
> It seems to me that bugs/problems sometimes creeps in or remains
> undetected, due to this or that developer not being able to test this or
> that tool.
>
> I have had some success in using stubs for the tools for which I do
> builders. The reasoning being that when testing my builders the primary
> concern is to test that SCons provides the correct files and flags. Of
> course at some point I also need to verify that the tools is properly
> called, but by using a stub anyone can run the test, even if the tool is
> not present on the system.
>
> The stubs are just simple scripts which emulates the actual tools with
> respect to accepting input and generating some sort of output. One
> approach could be to write the tool command line to the output file, and
> then just test that the command line was as expected by inspecting the
> file. As all my builders rely on a a construction variable to point at
> the binary I can simply replace the actual binary with the stub when
> doing my testing.
>
> In my own case my builders silently assume that the tools are present on
> the system, without doing any detection, which is a simplification
> compared to the test requirements for scons. Also I am aware that
> emitters and scanners might make things somewhat more complicated.

We do use stubs in a lot of the test scripts, and have lately been trying
to move the scripts in general towards cleanly separating stubbed scripts
from ones that still use the live tools.

You usually want some ability to still live tools as a sanity check,
because it usually takes a fair amount of trial-and-error work to get
your stub to exactly mimic the behavior of all the corner cases in a
complicated tool. Think of trying to implement a stub (or set of stubs)
that exactly mimc all of the complicated behaviors of all the different
versions of Visual Studio, for example, especially when you have to
stub out not only the tool behavior itself, but also the interaction
with the Windows registry...

So in any event, the fact that the technique isn't used more heavily isn't
because we haven't thought of it, but because it's a pretty complicated
issue and it simply hasn't been done for all of the tools. If you'd
like to contribute patches that implement stubs for some of these tools
that you have access to, and convert more test scripts to using them,
it would be *very* welcome.

Thanks,

         --SK

Suggestion for testing WAS: REVIEW: use smart C/C++ linking in the Intel tool chain (Dmitry Girgorenko and Gary Oberbrunner)

Author mortenelo
Full name Morten Elo Petersen
Date 2007-03-07 01:01:20 PST
Message Hi,

Just a thought or friendly suggestion!

I am by no means confident with the SCons test suite, but still I would
like to provide a suggestion.

It seems to me that bugs/problems sometimes creeps in or remains
undetected, due to this or that developer not being able to test this or
that tool.

I have had some success in using stubs for the tools for which I do
builders. The reasoning being that when testing my builders the primary
concern is to test that SCons provides the correct files and flags. Of
course at some point I also need to verify that the tools is properly
called, but by using a stub anyone can run the test, even if the tool is
not present on the system.

The stubs are just simple scripts which emulates the actual tools with
respect to accepting input and generating some sort of output. One
approach could be to write the tool command line to the output file, and
then just test that the command line was as expected by inspecting the
file. As all my builders rely on a a construction variable to point at
the binary I can simply replace the actual binary with the stub when
doing my testing.

In my own case my builders silently assume that the tools are present on
the system, without doing any detection, which is a simplification
compared to the test requirements for scons. Also I am aware that
emitters and scanners might make things somewhat more complicated.

regards
Morten

> Gary, I decided to put Dmitry's test in a new test/Intel subdirectory.
> I don't have the Intel compiler installed so I couldn't test
> it directly.
> It looks pretty simple, but I'd appreciate it if you could validate it
> and let me know if it needs a follow-on patch.

Re: [scons-dev] REVIEW: use smart C/C++ linking in the Intel tool chain (Dmitry Girgorenko and Gary Oberbrunner)

Author garyo
Full name Gary Oberbrunner
Date 2007-03-06 13:58:12 PST
Message Steven Knight wrote:
> Thanks for testing; let's do this next one *before* I check it in... :-)
>
> The test infrastructure does have a detect_tool() method; I should have
> just used that from the beginning.
>
> Could you test the patch below and let me know if it works out of the
> box for you?

Almost. Had to do this:
  intelc = test.detect_tool('intelc', prog='icpc')
i.e. add prog='icpc', since detect_tool not only detects the tool but has to
find a program of the same name unless you pass prog.

-- Gary

Re: [scons-dev] REVIEW: use smart C/C++ linking in the Intel tool chain (Dmitry Girgorenko and Gary Oberbrunner)

Author stevenknight
Full name Steven Knight
Date 2007-03-06 13:44:04 PST
Message Hi Gary--

>> Gary, I decided to put Dmitry's test in a new test/Intel subdirectory.
>> I don't have the Intel compiler installed so I couldn't test it directly.
>> It looks pretty simple, but I'd appreciate it if you could validate it
>> and let me know if it needs a follow-on patch.
>>
> ...
>> + + icpc = test.where_is('icpc')
>
> This doesn't work well, since icpc is normally installed in
> /opt/intel/{cc,cce}/​x.y.zzz/bin/icpc
> rather than somewhere on a "normal" user's path. Since I use scons I've never
> bothered to put it on my path! ;-) But if I hardcode the path in the test it
> works OK (fails without the patch, succeeds with it). Can the test use the
> tool's detect() method to detect it, or is that hard?
>
> Also, I had to add "#include <iostream>" to the top of hello.cpp to avoid a
> warning.

Thanks for testing; let's do this next one *before* I check it in... :-)

The test infrastructure does have a detect_tool() method; I should have
just used that from the beginning.

Could you test the patch below and let me know if it works out of the
box for you?

         --SK

*** /home/scons/scons/br​anch.0/branch.96/bas​eline/test/Intel/icp​c-link.py 2007-03-06 15:20:32.000000000 -0600
--- /home/knight/SCons/s​cons.0.96.C755/test/​Intel/icpc-link.py 2007-03-06 15:41:49.000000000 -0600
***************
*** 35,50 ****

   test = TestSCons.TestSCons()

! icpc = test.where_is('icpc')
! if not icpc:
! test.skip_test("Could not find 'icpc'; skipping test(s).\n")

! test.write('SConstruct', """
   env = Environment(tools=['default', 'intelc'])
   env.Program('hw', 'hw.cpp')
   """)

   test.write('hw.cpp', """\
   int
   main()
   {
--- 35,51 ----

   test = TestSCons.TestSCons()

! intelc = test.detect_tool('intelc')
! if not intelc:
! test.skip_test("Could not load 'intelc' Tool; skipping test(s).\n")

! test.write('SConstruct', """\
   env = Environment(tools=['default', 'intelc'])
   env.Program('hw', 'hw.cpp')
   """)

   test.write('hw.cpp', """\
+ #include <iostream>
   int
   main()
   {

Re: [scons-dev] REVIEW: use smart C/C++ linking in the Intel tool chain (Dmitry Girgorenko and Gary Oberbrunner)

Author garyo
Full name Gary Oberbrunner
Date 2007-03-06 13:32:29 PST
Message Steven Knight wrote:
> Gary, I decided to put Dmitry's test in a new test/Intel subdirectory.
> I don't have the Intel compiler installed so I couldn't test it directly.
> It looks pretty simple, but I'd appreciate it if you could validate it
> and let me know if it needs a follow-on patch.
>
...
> + + icpc = test.where_is('icpc')

This doesn't work well, since icpc is normally installed in
  /opt/intel/{cc,cce}/​x.y.zzz/bin/icpc
rather than somewhere on a "normal" user's path. Since I use scons I've never
bothered to put it on my path! ;-) But if I hardcode the path in the test it
works OK (fails without the patch, succeeds with it). Can the test use the
tool's detect() method to detect it, or is that hard?

Also, I had to add "#include <iostream>" to the top of hello.cpp to avoid a
warning.

-- Gary

RE: [scons-dev] REVIEW: use smart C/C++ linking in the Intel tool chain (Dmitry Girgorenko and Gary Oberbrunner)

Author Sohail Somani <s dot somani at fincad dot com>
Full name Sohail Somani <s dot somani at fincad dot com>
Date 2007-03-06 12:30:54 PST
Message > -----Original Message-----
> From: Steven Knight [mailto:knight at baldmt dot com]
> Sent: Tuesday, March 06, 2007 11:33 AM
> To: dev at scons dot tigris dot org
> Subject: [scons-dev] REVIEW: use smart C/C++ linking in the
> Intel tool chain (Dmitry Girgorenko and Gary Oberbrunner)
>
> Gary, I decided to put Dmitry's test in a new test/Intel subdirectory.
> I don't have the Intel compiler installed so I couldn't test
> it directly.
> It looks pretty simple, but I'd appreciate it if you could validate it
> and let me know if it needs a follow-on patch.

Maybe Intel should give you one seeing as they use Scons themselves :)

REVIEW: use smart C/C++ linking in the Intel tool chain (Dmitry Girgorenko and Gary Oberbrunner)

Author stevenknight
Full name Steven Knight
Date 2007-03-06 11:32:38 PST
Message Gary, I decided to put Dmitry's test in a new test/Intel subdirectory.
I don't have the Intel compiler installed so I couldn't test it directly.
It looks pretty simple, but I'd appreciate it if you could validate it
and let me know if it needs a follow-on patch.

         --SK

*** /home/scons/scons/br​anch.0/branch.96/bas​eline/src/CHANGES.tx​t 2007-03-06 03:50:28.000000000 -0600
--- /home/knight/SCons/s​cons.0.96.C754/src/C​HANGES.txt 2007-03-06 12:26:15.000000000 -0600
***************
*** 10,15 ****
--- 10,19 ----

   RELEASE 0.96.96 - XXX

+ From Dmitry Grigorenko and Gary Oberbrunner:
+
+ - Use the Intel C++ compiler, not $CC, to link C++ source.
+
     From Steven Knight:

     - Back out (most of) the Windows registry installer patch, which
*** /home/scons/scons/br​anch.0/branch.96/bas​eline/src/engine/SCo​ns/Tool/intelc.py 2007-01-31 00:20:57.000000000 -0600
--- /home/knight/SCons/s​cons.0.96.C754/src/e​ngine/SCons/Tool/int​elc.py 2007-03-06 12:25:12.000000000 -0600
***************
*** 353,359 ****
       else:
           env['CC'] = 'icc'
           env['CXX'] = 'icpc'
! env['LINK'] = '$CC'
           env['AR'] = 'xiar'
           env['LD'] = 'xild' # not used by default

--- 353,361 ----
       else:
           env['CC'] = 'icc'
           env['CXX'] = 'icpc'
! # Don't reset LINK here;
! # use smart_link which should already be here from link.py.
! #env['LINK'] = '$CC'
           env['AR'] = 'xiar'
           env['LD'] = 'xild' # not used by default

*** /dev/null 2006-10-09 06:24:02.712960312 -0500
--- /home/knight/SCons/s​cons.0.96.C754/test/​Intel/icpc-link.py 2007-03-06 12:24:20.000000000 -0600
***************
*** 0 ****
--- 1,58 ----
+ #!/usr/bin/env python
+ #
+ # __COPYRIGHT__
+ #
+ # Permission is hereby granted, free of charge, to any person obtaining
+ # a copy of this software and associated documentation files (the
+ # "Software"), to deal in the Software without restriction, including
+ # without limitation the rights to use, copy, modify, merge, publish,
+ # distribute, sublicense, and/or sell copies of the Software, and to
+ # permit persons to whom the Software is furnished to do so, subject to
+ # the following conditions:
+ #
+ # The above copyright notice and this permission notice shall be included
+ # in all copies or substantial portions of the Software.
+ #
+ # THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY
+ # KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE
+ # WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ # NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
+ # LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
+ # OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
+ # WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
+ #
+
+ __revision__ = "__FILE__ __REVISION__ __DATE__ __DEVELOPER__"
+
+ """
+ Simple "Hello, world" test of linking with the Intel C++ compiler, icpc.
+
+ This tests for a bug (1415) where our initialization of the linker to
+ $CC prevented automatic linking of C++ source.
+ """
+
+ import TestSCons
+
+ test = TestSCons.TestSCons()
+
+ icpc = test.where_is('icpc')
+ if not icpc:
+ test.skip_test("Could not find 'icpc'; skipping test(s).\n")
+
+ test.write('SConstruct', """
+ env = Environment(tools=['default', 'intelc'])
+ env.Program('hw', 'hw.cpp')
+ """)
+
+ test.write('hw.cpp', """\
+ int
+ main()
+ {
+ std::cout<<"hw\\n";
+ return 0;
+ }
+ """)
+
+ test.run(arguments = '.')
+
+ test.pass_test()
Messages per page: