On Tue, Sep 9, 2014 at 12:03 PM, Kenny, Jason L <[email protected]> wrote:
> I think you are missing the point or maybe I am. > > > > Given the tool revamp. > > > > How will we support: > > > > 1) Cross-builds. > > a. I want to build 32-bit and 64- at the same time > > b. I want to build for android arm and x86 > I have in mind something like this: # define and register the tools, by name Tool(name='intelc_32_arm', class=Tool.IntelC, abi='ia32', sys='arm') Tool.IntelC(name='intelc_64', class=Tool.IntelC, , abi='x86_64', sys='intel') # use them env1=Environment(tools=['intelc_32_arm', ...]) env2 Environment(tools=['intelc_64', ...]) > 2) Selecting different versions of gcc? > Same method. Tool(name='ancient_gcc', class=Tool.GCC, version='3.4') Environment(tools=['ancient_gcc']) > 3) How do I iterate over the different versions of a tool that are > installed > I haven't defined a tool enumeration API yet, but since there's a registry that stores everything, it shouldn't be hard. > 4) How do I know this this gcc tool will build x86 code or x86_64 > code, will it be android, mac or linux, phi, etc? > If you use the default version (don't pass special args to the tool), it ought to auto-detect the current platform. > 5) I want use gcc not clang with icc or I want to use a given > version of gcc (or cl) with icc. > Use a toolchain: my_tools = Toolchain(['my_icc', 'ancient_gcc']) > For me the issue is that SCons makes this HARDER than it needs to be. What > I am suggesting is that tools have certain traits. Not a lot, just some > basic stuff, I am suggesting that we need to define in SCons these objects > to make easy building blocks: > > > > 1) Platform Object – defines a system os, arch ( maybe more as it > can be clearly defined). Used to define a HOST and TARGET value in the > environment ( like in Parts) > I want to avoid having to define and implement this right now -- I think it's a fine idea, it's just orthogonal to revamping the _basic infrastructure_ of tools and chains. If we define a Platform object and Tool authors take a Platform as one arg for their tool: my_platform = Platform(...) Tool(name='my_icc', class=Tool.IntelC, platform=my_platform) then that is great. But LaTex, m4, SQL, and a million other tools wouldn't find that Platform object useful or important. We can layer it in later. > 2) Tools Object - defines a tool builder, basic variable, tells us > information ( such as it exists), populates the env[ENV] with needed values > to run. > Yes. I hope I am achieving this. > 3) Toolchain allows us to define changes, much like you define > I don't see it as defining changes. I see it as enabling grouping of tools into larger clusters or configurations or whatever you call it. Both AND (all must exist) and OR (select an alternative) are important. > 4) Configuration – to allow one to easily define common setting to > apply to a configured tool > Not sure what you're getting at here. Do tool args help? > 5) Toolsetting/info/finders – a set of basic objects to help find > information. You seem against this, but I suggest this as building blocks > to make it easy for a tool to setup and cache, etc a given tool. The fact > is that most tools have the same pattern and can be configured by replacing > some basic values. > Are you talking about adding some utility methods to the base Tool class, like looking up things in paths and registry? I'm fine with that. > 6) A version object. I know you might find this complex, but more > complex version handling this is really useful. And honestly is a common > need when one is making larger system. You can live without it, but having > it is really nice, and reduces common errors. > I think this would be nice. Again, not necessarily as part of the toolchain revamp, but yes if we had a version object that allowed flexible comparisons that would be very useful. I think the idea of a tool registry is a great idea, as long as it can > support different tools impls of the same tool in some way. > See above. My current implementation memoizes based on the tool's class and all the args passed to it. This assumes that the construction of a tool isn't dependent on external state, only the class and args. I actually think that restriction is useful to clarify and enforce the underlying concept. (Right now I have it so if you try to re-register the tool with the same args, it just returns the original.) If your tool should behave differently (when constructed, not just when applied to an env) then it should take an arg to indicate that. abi is an obvious one for C-like tools. -- Gary
_______________________________________________ Scons-dev mailing list [email protected] https://pairlist2.pair.net/mailman/listinfo/scons-dev
