What are your thoughts on infra to help provide a common mean to find tools for different platforms.
I believe what I have in Parts for this work pretty well. It allow an extensible and generally easy way for one to define how to find a given tool version(s) for a some combination of host and target. Being able to update a file with information about a new version without having to modify existing code I have found to be a big win. Given cases the how SCons deal with the Intel Compler vs how Parts does. It has been very easy for me in Parts to support the intel compiler versions and different platforms such as x86, x86_64, phi (k1om),ia64 , and some other case I cannot talk about for different system ( as window, posix, mac, and some others…). Likewise I have little issue with msvc for x86,x86_64, arm as well as WDK cases. I believe we when we talk about the toolchains and tools we need to consider: 1) Host we are on 2) What target platform we are building for ( so we select the best tool) 3) What version ( normally use exactly this version, or best version of a certain version ie latest 4.x drop, or the latest). The point here is that a tool needs to have a version value ( it might be wild in certain cases, but the common case for most tools, is that you can have more than one version at a time installed) When we configure an environment we need to consider all a setting up the value via: 1) Some hand defaults 2) Processing some script 3) Allowing the user to saw just use the shell and trust me Make users like 3) the most as that is how make works, and so simple builds this is not so bad. But for cross building this is a mess, and for teams 1,2 become very useful as this allow for a duplicate-exact setup which means the builds are reproducible, cases like 3) require a copy-exact setup, and I generally see this get messed up to easily, causing wasted time on some strange issue, cause by some difference that was not duplicated correctly. I think what I have here in parts is generally useful. I also believe that for use to get tools and toolchain more correct, we need to deal with the platform better in SCons, I have a SystemPlatform object and API to allow adding new platform combination easily. Likewise I have a generally useful Version object. Jason From: Scons-dev [mailto:[email protected]] On Behalf Of Gary Oberbrunner Sent: Tuesday, September 9, 2014 9:38 AM To: SCons developer list Subject: Re: [Scons-dev] This morning's WTF moment This is python, so a get_last_error type API is really simple. It can just store the message in the tool class. Also, I expect exists() to be cached for speed (based on the tool's args) so when the tool doesn't exist it will need to store the message anyway, to return it to future callers. exists_error() just becomes an accessor for that member var. That basically means your double-negative version is no different than the regular version in terms of implementation, and I think the exists() + exists_error() API is nicer. I don't really like the "error object", i.e. something that tests as False but has a string value. -- Gary On Tue, Sep 9, 2014 at 9:56 AM, Kenny, Jason L <[email protected]<mailto:[email protected]>> wrote: We have two options it seems: 1) Add a exists_error_msg() like API. 2) Or return an error object. Thoughts on 1): The main value with 1) is the exists is very simple in that it returns True or False. The main issue with it is that it is a bit more complex to implement a get last error like API. There are a number possible Issues such as memory waste can easily become an problem, Not having a simple API to use this for a tool writer I would see as being needed to help keep this logic easy to implement from the tool writers point of view and not adding resource and or correctness issues to SCons. Or the implementation may just need to re-test. So maybe the way to view this API is to instead view it like the inverse ie.. not_exist() ie this would return a string ( ie the message) when it does not exists and None when it does exists. Then exist would always be a impl like: def exists(): return not_exists() When the user wants to see why it does not exist they would call the not_exists() api. Which would provide a message. If used directly the logic of If !not_exists(): will work correctly ( yes it a double neg here.. ewww) This might be a way to do this, without a special object while keeping it simpler to implement. Thoughts on 2) The value of an error object is that it can work be easily made to work in basic testing cases, while allowing the returning of extra information such as information about what is wrong. It could be mixed with use of True, as in this case we most likely will not have a message to share whereas false we will. The main con to an error object is that the user has to return this object, which is a little more complex than returning False, but not as complex as trying to implement a GetLastError() like API. Jason From: Scons-dev [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Gary Oberbrunner Sent: Tuesday, September 9, 2014 4:56 AM To: SCons developer list Subject: Re: [Scons-dev] This morning's WTF moment On Tue, Sep 9, 2014 at 4:03 AM, Jean-Baptiste Lab <[email protected]<mailto:[email protected]>> wrote: Or wouldn't it be enough to simply mandate that exists() return something that can be tested against True/False? If that's the case, wouldn't a bit of wrapping around and implementing the __eq__/__neq__ descriptors (possibly __cmp__) be good enough so that we can get to the error description when needed (if False) without breaking existing usages? I did think about that. It's hard for me to imagine something that can test as false while still having a string value. Not impossible, but pretty weird and a bit un-pythonic. I prefer simplicity over cleverness. Still, if you have an idea, let me know. -- Gary _______________________________________________ Scons-dev mailing list [email protected]<mailto:[email protected]> https://pairlist2.pair.net/mailman/listinfo/scons-dev -- Gary
_______________________________________________ Scons-dev mailing list [email protected] https://pairlist2.pair.net/mailman/listinfo/scons-dev
