Hi Ant already works for some Java modules, though at a module-only level. I did get gbuild to extract dependency information from Ant, and build Ant modules in the right order. For C++ though, I don't see how Ant is possible. Even if we do get it to call the C++ compiler, it doesn't support parallel builds. Also Ant is quite old, its build.xml file format wasn't designed to be verifiable by an XML schema.
I should have some time for more AOO development in a week or so. I've been stuck on porting the "config" build API to gbuild (which seems to be some sort of API for XML configuration of UNO components, and schemas and XSLT code to verify them at build time - main/solenv/inc/tg_config.mk); once that's ported, 9 more modules should be portable to gbuild. That has been particularly difficult, and it seems to affect post-build packaging too. Another 8 modules relate to Windows. I'll have to setup up a fuller Windows build environment for those, and I wonder if they need updating - several of them use .NET 2. It was quite encouraging to see that on Win64, several modules that didn't build in dmake, started building once they were converted to gbuild. In other news, I've been playing around with Wine, to try and cross-compile the Windows version of AOO without Windows. I helped fix a Wine bug that was crashing Cygwin scripts during installation and making the install take hours ( https://source.winehq.org/git/wine.git/commit/2e53f8bccb65d112e5e341586c730094950fe6c3). Cygwin installed nicely on Wine, bash builtin commands started working. Then I ran into a bug where Cygwin expects user APCs to be called during DLL loading, and Wine's DLL loading doesn't call any wait functions that would trigger calling APCs, so a thread that would be created by an APC doesn't get created, so fork() hangs waiting for that thread to suspend all other threads and copy their memory to the child process (which is the only way to fork() properly on Windows). Patching Cygwin to create that thread directly (without using APCs) gets it further, fork() creates the child process, but then fails an assertion and aborts because some data structure in the child process is not at the expected address. If we can get a working Windows build environment set up in Wine, we should hopefully reduce build times for the Windows build from the current 5-8 hours, closer to the 90 minutes it takes for the *nix build. AOO itself installed and worked in Wine since OpenOffice.org version 1, so we should be able to both build and test in Wine. Of course, there is also the question of how well the Platform SDK and other dependencies work on Wine. But I am quite optimistic. Cygwin is unique in messing around with low-level operating system implementation details. It even binary-patches some functions in NTDLL.DLL to speed up getting the current working directory (which is apparently slow on Windows). On Wed, Oct 30, 2019 at 7:25 AM Peter Kovacs <peter.kov...@posteo.de> wrote: > Hello Damjan and all > > > I would like to re-discuss our current plan. Hoping to gain a common view. > > Current state is mostly we use gmake, there are still some difficult to > migrate dmake projects. And we use Ant for java. > > The plan is not to stop at the dmake -> gmake conversion but to move on > to scons, removing as much dependencies as we can. Right? > > I would like to set the target to build everything to Ant, removing as > much dependencies we can. > > > My arguments are mostly that Ant is supported by most when not all IDEs > and I would really like to have an IDE as working environment, and my > hope is that it is easier maybe to integrate an Ant build environment > then a scons or gmake environment. > > I think this would give us a better base then the plan above. So what > was the arguments against Ant again? > > > All the Best > > Peter > >
