That is not the problem. Replace `$PRINT_TASK` with `$SHCXX` (or any other pre-defined thing).
Note that replacing '$PRINT_TASK > $TARGET' with '$PRINT_TASK.path > $TARGET' It suddenly starts to work. Same thing happens if I replace env['PRINT_TASK'] = prints[int(ARGUMENTS['use_task'])] with env['PRINT_TASK'] = prints[int(ARGUMENTS['use_task'])].path or env['PRINT_TASK'] = str(prints[int(ARGUMENTS['use_task'])]) The is analogous to changing compiler version. I.e. pointing to a different compiler binary from a different directory, which is exactly how I stumbled upon this. I changed my Environments CC, SHCXX, and others to point to newer version only to discover that SCons decided that everything is up to date. That doesn't sound correct. On 6 May 2016 at 16:40, Bill Deegan <[email protected]> wrote: > Likely the issue is that there is no source for the command that creates > result.txt. > If I'm reading your logic correctly I think it should be '$PRINT_TASK" > > As you can see from the --tree=prune result.txt doesn't depend on > anything. so there's no need to rerun it. > > Also try running with --debug=explain > > -Bill > > On Fri, May 6, 2016 at 11:26 AM, Krzysztof Trzciński < > [email protected]> wrote: > >> No. I am saying it behaves the same way in both versions. >> >> $ scons use_task=0 --tree=prune >> scons: Reading SConscript files ... >> 1/print >> 2/print >> scons: done reading SConscript files. >> scons: Building targets ... >> scons: `1/print' is up to date. >> +-1/print >> +-1/print.o >> | +-1/print.cc >> | | +-#include <iostream> >> int main() >> { >> std::cout << "Printing " << 1 << std::endl; >> return 0; >> } >> >> | +-/usr/bin/g++ >> +-/usr/bin/g++ >> scons: `2/print' is up to date. >> +-2/print >> +-2/print.o >> | +-2/print.cc >> | | +-#include <iostream> >> int main() >> { >> std::cout << "Printing " << 2 << std::endl; >> return 0; >> } >> >> | +-/usr/bin/g++ >> +-/usr/bin/g++ >> scons: `result.txt' is up to date. >> +-result.txt >> scons: done building targets. >> >> $ scons use_task=1 --tree=prune >> scons: Reading SConscript files ... >> 1/print >> 2/print >> scons: done reading SConscript files. >> scons: Building targets ... >> scons: `1/print' is up to date. >> +-1/print >> +-1/print.o >> | +-1/print.cc >> | | +-#include <iostream> >> int main() >> { >> std::cout << "Printing " << 1 << std::endl; >> return 0; >> } >> >> | +-/usr/bin/g++ >> +-/usr/bin/g++ >> scons: `2/print' is up to date. >> +-2/print >> +-2/print.o >> | +-2/print.cc >> | | +-#include <iostream> >> int main() >> { >> std::cout << "Printing " << 2 << std::endl; >> return 0; >> } >> >> | +-/usr/bin/g++ >> +-/usr/bin/g++ >> scons: `result.txt' is up to date. >> +-result.txt >> scons: done building targets. >> >> >> P.S. Yes, I noticed I've broadcasted my password as soon as I saw it come >> back to me from list. Already have changed it. >> >> On 6 May 2016 at 13:43, Bill Deegan <[email protected]> wrote: >> >>> >>> >>> On Fri, May 6, 2016 at 8:36 AM, Bill Deegan <[email protected]> >>> wrote: >>> >>>> Greetings, >>>> >>>> The scons dev mailing list is intended for discussion development of >>>> scons itself. >>>> >>>> Bugs should be initially discussed on the users mailing list. Thus I'm >>>> cc'ing that list. Please move the discussion there. >>>> >>>> Thanks, >>>> Bill >>>> >>>> On Fri, May 6, 2016 at 3:30 AM, Krzysztof Trzciński < >>>> [email protected]> wrote: >>>> >>>>> Below is fully self contained SConstruct showing (I think) a bug >>>>> (interesting bits at the end): >>>>> >>>>> env = Environment(tools=['default', 'textfile']) >>>>> >>>>> # That bit is not that important. >>>>> # It just creates to programs, one of which >>>>> # prints "1" and the other prints "2". >>>>> # It just emulates having i.e. two versions of compiler >>>>> # (in different directories). >>>>> prints = [] >>>>> for num in (1,2): >>>>> printcc = env.Textfile( >>>>> '{0}/print.cc'.format(num), >>>>> [( >>>>> '#include <iostream>\n' >>>>> 'int main()\n' >>>>> '{{\n' >>>>> ' std::cout << "Printing " << {0} << std::endl;\n' >>>>> ' return 0;\n' >>>>> '}}\n' >>>>> ).format(num),], >>>>> ) >>>>> >>>>> prints.extend(env.Program( >>>>> '{0}/print'.format(num), >>>>> printcc >>>>> )) >>>>> >>>>> for p in prints: >>>>> print p.path >>>>> >>>>> >>>>> # Here starts the important bit. >>>>> # This is not actual use case, actual use case for me was >>>>> # changing compiler version (by changing base directory >>>>> # of all my tools to newer version). >>>>> # For ease of use this takes `use_task` argument to select >>>>> # which "compiler version" to use. >>>>> >>>>> env['PRINT_TASK'] = prints[int(ARGUMENTS['use_task'])] >>>>> >>>>> # And now the build command dependent on >>>>> # on "compiler". >>>>> >>>>> result = env.Command( >>>>> 'result.txt', >>>>> [], >>>>> '$PRINT_TASK > $TARGET' >>>>> ) >>>>> >>>>> Default(prints+result) >>>>> >>>>> Now let's see how it works: >>>>> >>>>> # Let's use "older compiler": >>>>> >>>>> $ scons use_task=0 >>>>> scons: Reading SConscript files ... >>>>> 1/print >>>>> 2/print >>>>> scons: done reading SConscript files. >>>>> scons: Building targets ... >>>>> Creating '1/print.cc' >>>>> g++ -o 1/print.o -c 1/print.cc >>>>> g++ -o 1/print 1/print.o >>>>> Creating '2/print.cc' >>>>> g++ -o 2/print.o -c 2/print.cc >>>>> g++ -o 2/print 2/print.o >>>>> 1/print > result.txt >>>>> scons: done building targets. >>>>> >>>>> $ cat result.txt >>>>> Printing 1 >>>>> >>>>> # All built fine and looking good. >>>>> >>>>> # Now let's use "newer compiler". >>>>> # This one should produce "2" in result.txt >>>>> >>>>> $ scons use_task=1 >>>>> scons: Reading SConscript files ... >>>>> 1/print >>>>> 2/print >>>>> scons: done reading SConscript files. >>>>> scons: Building targets ... >>>>> scons: `1/print' is up to date. >>>>> scons: `2/print' is up to date. >>>>> scons: `result.txt' is up to date. >>>>> scons: done building targets. >>>>> >>>>> $ cat result.txt >>>>> Printing 1 >>>>> >>>>> # Yet it doesn't! It says it is already up to date! >>>>> # HERE it went wrong. >>>>> >>>>> # Some sanity checks to verify it is incorrectly >>>>> # reporting state. >>>>> # Let's just check if building that file first with >>>>> # use_task=1 gives us "2" in file. >>>>> # First remove result.txt to force build. >>>>> >>>>> $ rm result.txt >>>>> >>>>> # Then build with "new compiler". >>>>> >>>>> $ scons use_task=1 >>>>> scons: Reading SConscript files ... >>>>> 1/print >>>>> 2/print >>>>> scons: done reading SConscript files. >>>>> scons: Building targets ... >>>>> scons: `1/print' is up to date. >>>>> scons: `2/print' is up to date. >>>>> 2/print > result.txt >>>>> scons: done building targets. >>>>> >>>>> $ cat result.txt >>>>> Printing 2 >>>>> >>>>> # And this time it executed new compiler >>>>> # which gave expected result of "2". >>>>> >>>>> # If I switch back to old one it again reports >>>>> # result to up to date incorrectly: >>>>> >>>>> $ scons use_task=0 >>>>> scons: Reading SConscript files ... >>>>> 1/print >>>>> 2/print >>>>> scons: done reading SConscript files. >>>>> scons: Building targets ... >>>>> scons: `1/print' is up to date. >>>>> scons: `2/print' is up to date. >>>>> scons: `result.txt' is up to date. >>>>> scons: done building targets. >>>>> >>>>> So bottom line seems to be that SCons is missing out on dependencies. >>>>> When a substition value is a file node it seems to only look at ` >>>>> node.name`, not whole `node.path`, causing incorrect rebuilds. >>>>> >>>>> I have checked and it seems to behave that way on 2.5.0 version >>>>> (everyday we got stuck on 2.1.0). >>>>> >>>>> Is this a bug? If not what is the explanation of this behaviour? >>>>> >>>> >>> So you're saying this works on 2.1.0 and not on 2.5.0? >>> Can you paste the output of: >>> scons --tree=prune >>> For each argument value? >>> >>> -Bill >>> p.s. posting your mailman password publically as you did in you initial >>> posting at the end is not a god idea. If you can change it, I'd recommend >>> you do. >>> >>> _______________________________________________ >>> Scons-dev mailing list >>> [email protected] >>> https://pairlist2.pair.net/mailman/listinfo/scons-dev >>> >>> >> >> _______________________________________________ >> Scons-dev mailing list >> [email protected] >> https://pairlist2.pair.net/mailman/listinfo/scons-dev >> >> > > _______________________________________________ > Scons-dev mailing list > [email protected] > https://pairlist2.pair.net/mailman/listinfo/scons-dev > >
_______________________________________________ Scons-dev mailing list [email protected] https://pairlist2.pair.net/mailman/listinfo/scons-dev
