Hi again;
Some answers, although this all classifies as "musings" ;).
To damjan:
> AFAIK all make utilities suffer from the recursive make problem, the
> only way gbuild didn't is by using the eval feature in GNU make, and
> it still left a lot to be desired.
Concerning FreeBSD's make, unlike CMake it doesn't depend on any
external make, but just like gmake it can give control to other build
engines, as is done in the ports tree. We never do that for the base
system: all the contrib packages in base have their own bmake scripts.
If it is better/nicer than gmake is a matter of taste.
The recursive make issue is somewhat unavoidable in AOO: When we build
external dependencies we use the same system used by the native packages
to build. The only thing we do avoid (through patches) is
calling the "configure" scripts.
So just for reference:
- We use Vigra, but we can't update it more than we already have because
the newer version depends on CMake, and that would mean
adding a dependency to CMake in all platforms.
- Updating redland is really painful due to concatenated configure
builds, I stopped looking at that.
- We do require ant for Java stuff.
- As you mention we now need scons for serf.
>> - We have somewhat of a chicken and egg problem now with Python as
>> the build system is making it difficult to update our copy to
>> something like 2.7.11 that supports newer Windows compilers.
>>
>>
> Please elaborate.
As mentioned above, we use the native build system in some packages.
In the case of CPython we use gmake for python unless we are in Windows
where we use the native project files. The latest versions of Python
completely updated the windows project files for newer MSVC versions,
which basically means that:
1) Whomever wants to do an update needs to have access to both Windows
and UNIX machines.
2) Python 2.7.11 may not build on the old MSVC required for AOO.
To Dennis:
...
> With regard to Pedro's comments about Python, there is no reason to
> use IronPython, which is a .NET system, similarly with how Jython
> operate in and for Java.
For me there is a reason to use IronPython: I want to take advantage of
all the power I can from the native platform. Being able to use
IronPython or Active Python would be a nice thing.
Unfortunately at least IronPython and Jython are off-limits for AOO:
we pretty much depend on CPython for the pyuno bridge. Using the
stock CPython provided by python.org would be an OK solution. I
do think (and I think everyone agrees) that we should move away
from cygwin into more native versions. May I remind people of
Strawberry Perl :).
We do have support for Python3 but I decided (since I was the one
doing the updates) to keep shipping Python27 for compatibility
reasons. So far I think it has been a wise decision.
Where I do think we are delayed, with regards to other projects,
is upgrading the MSVC toolset, but I just don't do Windows.
Pedro.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
