On Wed, Apr 15, 2020 at 3:15 PM Jim Jagielski <j...@jagunet.com> wrote:
On Apr 15, 2020, at 3:01 AM, Damjan Jovanovic <dam...@apache.org> wrote:
We are also thin on new contributors, and I recall you saying they're
largely scared off by the current build system.
Two points:
1. I doubt that by the time we finish porting to a whole new build
system, we will even have anyone *wanting* to contribute. With each delay
and push-out on releases, and more time spent working on the build system
instead of AOO itself, we become less and less relevant. Is that really a
priority we should be focusing on? Are the number of people knowledgeable
around scons really greater than what we have now? But I could be wrong,
which leads me to #2...
What would you recommend we focus on instead then?
Ideally, new contributors wouldn't need to be knowledgeable about scons.
The build should be easier to perform, hopefully just "./configure"
followed by "scons" (and scons even implements features that can subsume
./configure too). Already, scons doesn't need the "source winenv.set.sh"
and "cd instsetoo_native" steps to build its modules.
2. "The conversion from gbuild to scons would largely be automated, fast
and correct." If that is the case, let's test that theory right now.
This has been possible for some time. In the scons-build branch, you can do
the following:
$ cd gotoSCons
$ mvn package
$ java -cp target/gotoSCons-0.1-SNAPSHOT.jar
org.apache.openoffice.gotoSCons.GBuildConverter parsingAnalysis ../main
(per-module output)
Could parse: [MathMLDTD, UnoControls, animations, cosv, cppcanvas,
drawinglayer, eventattacher, fileaccess, i18nutil, idl, io, rdbmaker,
registry, remotebridges, sane, store, svgio, twain, ucbhelper, unixODBC,
xmlreader, xmlscript]
22 out of 105 gbuild modules are parseable
That means 22 modules can already be converted, completely and correctly.
As we add more features to the converter (AllLangResTarget, UnoApi, Junit,
GoogleTest, etc.), that 22 will increase.
The per-module gbuild files are easy to parse. Parsing the syntax takes
only 3 methods and < 100 lines of Java. The non-deterministic ones with
"ifeq ($(GUIBASE),aqua)" require some manual work, but even there, a lot
can be automated. There is some more work involved in semantic conversion:
understanding and converting specific gbuild commands, converting paths to
scons format, etc. but even so, we're on just 1913 lines of code in total
for the converter.
The hard part is to convert gbuild functions in main/solenv/gbuild into
scons, for example, the worst case scenario is AllLangResTarget, for which
this monstrous dependency tree needs to be implemented, with 4 layers of
intermediate targets and complex actions with side effects and header
dependencies (not shown):
# AllLangResTarget(name)
# (meta-target; delivers an empty timestamp file)
# ^ ^
# / \
# / \
# / \
# ResTarget(nameen-US,name,en-US)
ResTarget(nameen-GB,name,en-GB)
# $(WORKDIR)/ResTarget/$(resName).res
$(WORKDIR)/ResTarget/$(resName).res
# $(WORKDIR)/ResTarget/nameen-US.res
$(WORKDIR)/ResTarget/nameen-GB.res
# ^ ^ ^
# | rsc | |
# | | |
# SrsTarget SrsTarget
SrsTarget
# $(WORKDIR)/SrsTarget/$(srsName).srs
# $(WORKDIR)/SrsTarget/uui/res.srs
# ^
# | concatenate
# +----------+
# | \
# | \
# SrcPartTarget SrcPartTarget
# $(WORKDIR)/SrsPartTarget/$(srsPartName)
# $(WORKDIR)/SrsPartTarget/uui/source/ids.src
# ^ ^
# | rsc | rsc
# | |
# (when not translating) | | (when translating)
# | |
# | SrcPartMergeTarget
# | $(WORKDIR)/SrsPartMergeTarget/$(1)
# |
$(WORKDIR)/SrsPartMergeTarget/uui/source/ids.src
# | ^
# | /
# | / transex3
# | / (when translating)
# $(srsPartName) /
# uuid/source/ids.src
#
Damjan
