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 n
On Tue, Sep 9, 2014 at 4:03 AM, Jean-Baptiste Lab <
jeanbaptiste@gmail.com> 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__
On Mon, Sep 8, 2014 at 10:24 PM, William Blevins
wrote:
> This might be obvious, but it the exception pattern not popular in python?
Sure, but we don't want everyone testing for tool existence to have to wrap
that in an exception handler.
--
Gary
__
To test against True/False one should better implement __nonzero__, not
__eq__ or something :-) That way one could then use the form "if obj:", not
an ugly form of "if obj == True:".
Thanks,
Vasily
09 сент. 2014 г. 12:03 пользователь "Jean-Baptiste Lab" <
jeanbaptiste@gmail.com> написал:
> O
On 9 September 2014 11:56, Gary Oberbrunner wrote:
>
> On Tue, Sep 9, 2014 at 4:03 AM, Jean-Baptiste Lab <
> jeanbaptiste@gmail.com> 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
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
er
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. exist
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 t
On Tue, Sep 9, 2014 at 11:08 AM, Kenny, Jason L
wrote:
> 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
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
2) Selecting different versions of gcc?
3) How do I iterate o
On Tue, Sep 9, 2014 at 12:03 PM, Kenny, Jason L
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
For reference sake I added /etc/paths and /etc/path.d/* to the path since
it was claimed that Apple sanctioned it as the way to add paths to the
system and is used by Xquartz installation to add /opt/X11/bin to the
path. On my system it also catches the TexLive installation paths
/usr/texbin
*-*
Thanks Gary for your thoughts!
I have a few thought about the response. But I think I would start off with
just one item.
When you look at what you have suggested, we have a cross build you suggest
something to what I would think..
env1=Environment(tools=['intelc_32_arm', ...])
What is wrong w
On Tue, Sep 9, 2014 at 2:07 PM, Kenny, Jason L
wrote:
> Thanks Gary for your thoughts!
>
> I have a few thought about the response. But I think I would start off
> with just one item.
>
>
>
> When you look at what you have suggested, we have a cross build you
> suggest something to what I would
>>Well, much more interestingly, many tools' idea of the Platform has nothing
>>to do with what CPU it's running on. Might be GPU (NVIDIA/AMD), or network,
>>or Amazon instance type, or SQL configuration... who knows. What you're
>>proposing is too C-centric for a general build tool. Not sayi
15 matches
Mail list logo
