In the new build system, what is the status of automatic symbol
generation, needed for easy debug.
It is badly broken in 4.1.7, with most modules not getting symbols
generated despite --enable-symbols in the configure parameters. This has
cost me weeks of work on a debug project.
On 7/4/2020 11:44 AM, Damjan Jovanovic wrote:
Hi
In the scons-build branch, I've just pushed a set of 11 commits that
theoretically get 93 out of 105 gbuild modules (88.57%) automatically
converting to gbuild.
The "gotoSCons" converter and the SCons infrastructure in that branch have
now been developed to such a level that a module can be automatically
converted from gbuild to SCons, from where it can use SCons for all of the
following:
Building C/C++ objects
Linking shared libraries, static libraries, and executables
Building JUnit tests and running them
Building Google Tests and running them
Building .component files with XSLT
Running Ant sub-builds
Delivering "package" files such as headers
Even doing the impossibly difficult 5 step "AllLangResTarget" (.src ->
merged .src -> .srs -> .res for each language).
I still have to implement Jar, Zip, UnoApi, WinResTarget and SdiTarget, but
I think only Jar and Zip are worth implementing automatic conversion for,
as SdiTarget and UnoApi are only used in 5 places each, and WinResTarget in
only 2 places, which makes manual conversion for them easier. The hardest
conversions are already done.
Where does this leave us?
The gotoSCons converter can't support a number of features, like
non-deterministic constructs (ifeq ($(GUI),UNX)), custom make rules, etc. A
module can only be automatically converted if it doesn't use the
unsupported features. Currently, 35 modules use only supported features,
and can be converted automatically (this should increase to 39 modules when
I add Jar and Zip conversion).
Another 58 modules use non-deterministic constructs or custom make rules.
Converting those 58 could be done through a semi-automated process, which
involves editing the gbuild files to remove the unsupported features,
running the automated conversion on what is left, then manually patching
what was removed into the conversion results. Sometimes this is quick and
easy, at other times probably not.
The final 12 modules use unsupported targets requiring a longer and mostly
manual conversion to SCons, though even there the supported targets could
be converted automatically.
The SCons infrastructure does require some cleanup, as I was learning while
developing, and we still need library naming conversions, tests on
Linux/WIndows/Mac, etc.
The more I've used SCons, the more I've liked it. I've even started using
it in my own projects at work now. I've found a way to solve every problem
I've encountered, and the SCons developers have been helpful when I asked
them questions. Complex functionality like header dependency scanning,
automatic directory creation for output files, using @responsefile for long
command lines when necessary, and other features gbuild implements
manually, all work in SCons automatically. In 1816 lines of code, our SCons
infrastructure implements what took gbuild 9418 lines, and SCons is far
more readable and maintainable (even in its current messy state).
The plan isn't to merge this to trunk any time soon. Rather the idea is to
develop the converter even further, then when it's complete enough, convert
as many gbuild modules to SCons. Then measure performance of building those
modules en-masse with SCons alone - if there are performance problems at
that stage, they are only going to get worse with more modules.
The real test however is converting the other 78 dmake modules to SCons. 37
of them are 3rd party "externals" like jpeg and zlib, which have their own
build systems that we just call, so conversion is relatively easy. The
other 41 modules are hard to convert, but gbuild is one of the reasons that
they were hard, and where SCons is expected to make the greatest
difference. Only once we are building without dmake, without gbuild,
without build.pl, without Cygwin, on all platforms, then it would be the
right time to merge to trunk.
If at some stage in this process we are unhappy with SCons, and some better
build system can be found, it shouldn't be difficult to change to it. The
converter could output files for that other build system instead; at
present it's only 498 lines of code in 1 file, that are involved in writing
SCons build files, all we would need is a similar file for that other build
system.
Build systems are not the most exciting part of development, but bad build
systems make development painful, and as a large multi-platform project, we
build a lot. We answer build-related questions on the mailing lists too
often, and new contributors are put off by the current build system. A lot
of what we want to do with AOO, such as ports to Win64, AArch64, newer MSVC
versions, and so on, also involve build-related changes.
Damjan
--
This email has been checked for viruses by AVG.
https://www.avg.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
