>>Yes, the above is what we should aim for, with the toolchain revamp. >>Totally agree. However today, everyone would see those errors, even if not >>using C/C++ at all, and I'm afraid that's not acceptable. We need to call >>the tools "on demand" (which has challenges) and allow more flexible >>specification of what tools a user wants (cares about). >>
Well in SCon this is so.. but not general so in Parts. What was added, and I have proposed, was that you can provide which chain of tools you want. I can easy say: Scons --target=android-x86 --tool-chain=gcc There is no need for MS vc to be installed.. so there is no problem or error message. What you seem to suggest is different ability of loading a tool if it was needed. Which is to say if env.Program(...) was called Scons might know it needs a CC tool to build it and look at what CC tools exist and load a given compiler tool at that time, or check at the time if the requested tool for that type of really does exists. I don't see that as a major issue to tweak. I still see a need to formalize the idea of a toolchain in SCons so the user can control what set of tools to try to use when they want to. Anyways just some thoughts.. Jason _______________________________________________ Scons-dev mailing list [email protected] http://two.pairlist.net/mailman/listinfo/scons-dev
