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
