Do we need wxpython.org/Phoenix/tools ?

Just for my understanding of the very complex build process.

Why does http://wxpython.org/Phoenix/tools/ exists? Why doesn't the
build script just use the local installed versions of this tools?
And if they are not installed build.py should just give a informative
and human readable error message about it.

Background:
Loading such tools from a external and un-originial (no download from
the offical project sites) source make the build-script to complex and
causes errors. e.g. there is only a 64bit version of doxygen in the
tools-directory but the build.py doesn't check for the architecture.
(I will PR a bugfix of that.)

moonkid@posteo.org wrote:

Just for my understanding of the very complex build process.

Why does Index of /Phoenix/tools exists? Why doesn't the
build script just use the local installed versions of this tools?
And if they are not installed build.py should just give a informative
and human readable error message about it.

1. Because different versions of these tools can sometimes have very different behaviors, so using the same version everywhere can be very important.

2. By having build.py fetch the tools I don't need to manually update all of my development machines and buildbot environments, (6 to 10 of them depending on how things are configured at the time.) They update themselves instead.

3. If somebody doesn't like it or if there isn't a compatible version available via the tools folder then the user can override that with an environment variable.

4. Or they can use the source tarball instead which won't need any of the tools except waf, and it is Python code so platforms or architectures don't matter.

···

--
Robin Dunn
Software Craftsman

1. Because different versions of these tools can sometimes have very
different behaviors, so using the same version everywhere can be very
important.

I see. But good tools should have backwards-compatibility or they
should have flags to act like older versions.

2. By having build.py fetch the tools I don't need to manually update
all of my development machines and buildbot environments

That is a very important argument. I see.

3. If somebody doesn't like it or if there isn't a compatible version
available via the tools folder then the user can override that with
an environment variable.

I would suggest a patch with a global option flag that switch off
completely switch of the getTool() behavior fetching from wxPython.org.
With that flag activated only the local system tools are used. And if
they are no present an human readable error message will appear.

Would you accept a patch like that?

e.g. "--localtools"

···

On 2015-02-26 19:49 Robin Dunn <robin@alldunn.com> wrote:

moonkid@posteo.org wrote:

···

On 2015-02-26 19:49 Robin Dunn<robin@alldunn.com> wrote:

1. Because different versions of these tools can sometimes have very
different behaviors, so using the same version everywhere can be very
important.

I see. But good tools should have backwards-compatibility or they
should have flags to act like older versions.

2. By having build.py fetch the tools I don't need to manually update
all of my development machines and buildbot environments

That is a very important argument. I see.

3. If somebody doesn't like it or if there isn't a compatible version
available via the tools folder then the user can override that with
an environment variable.

I would suggest a patch with a global option flag that switch off
completely switch of the getTool() behavior fetching from wxPython.org.
With that flag activated only the local system tools are used. And if
they are no present an human readable error message will appear.

Would you accept a patch like that?

e.g. "--localtools"

Perhaps. Submit the PR and I'll take a look.

--
Robin Dunn
Software Craftsman