On Wed, Apr 15, 2020 at 6:46 AM Peter Kovacs <pe...@apache.org> wrote:
> If one wants to tap in our build system he needs to understand Perl, > shell, make, ant, XML, configure, ... > > This is just way to complicated, especially if you want to bring in an > IDE to ease code development. > > > Damjan is not very happy with the features gmake offers. I am not sure > where exactly the Issue is. > > He is opting for SCONs, with the option to extend the build system with > python. And IMHO on Damjan > > Side he is quite serious about it. > > > Everyone else has not expressed any opinion on this development, so I am > not sure everyone is aware. The last discussion on this topic, > > consent has been strongly to make gmake work. > We already took that approach to its limit, and I don't believe we can go much further. Most of gmake works by luck. The simplest things break, make no sense, and cannot be debugged, eg. sometimes *_add_files breaks, but *_add_file works, despite the fact the former just calls the latter. There are already some hacks in modules to work around gmake's brokenness... > > Another objection is that we got some heavy negative experience report > from the serf community about SCONS. > > It wasn't the entire "serf community", just brane@ on 30 Oct 2019: ---snip--- As a far-too-long-time user of Scons (in Serf), let me just add a caution: Scons is very, very broken and not at all well maintained. Writing a truly cross-platform, cross-toolchain SConstruct file for anything other than really trivial cases amounts to writing a *lot* of platform-specific Python code to make the builds work. If you're already moving to gmake (without autotools, and I expect using Cygwin on Windows), then I suggest you finish the transition, then leave well enough alone. ---snip--- My experience so far has been exactly the opposite: it is far easier to get scons building cross-platform, than GNU make + countless shell tools which also drag in the whole of Cygwin. To summarize quickly: I tried to avoid scons before and use gmake, and we already got as far as we could. scons is not a decision I made lightly, it's a decision I made because it's that good. Python isn't my favorite language, but what we gain from scons is significant enough for me to want to learn more Python. By using scons, Cygwin left the building without me even trying. scons has a 20 year history, supports OS/2 and numerous other platforms, supports Python 2 and 3, supports more MSVC versions than we do (including Visual Studio 2019), would allow us to build almost anywhere. It is packed full of many advanced features we need, like symlinking libX.so -> libX.so.2, automated header dependency scanning, flex, yacc, Java, Objective C, precompiled headers on MSVC, fully parallelizes builds across module boundaries, can work out minimal rebuilds using checksums of file contents instead of inode timestamps, is extensible by design, has readable source code, can be debugged, and is under a liberal license (MIT). I've looked, and nothing else really comes close; every other build tool would require considerable further development (AOO has already tried building big build systems around both dmake and GNU make; my better experience with Ant/Maven makes me more hopeful about a richer higher-level build tool that automates more of the work internally). The conversion from gbuild to scons would largely be automated, fast and correct. (We could also keep the scons files in a format that would allow easier automated conversion to something else later.) > Which are switching from, SCONS to cmake. > > > So in the end we do not have Consent where we want to go. And currently > it is heavily influenced by Damjan. And this is imho very thin. > > Then we were always very thin on gbuild too. You've also done some scons development. We are also thin on new contributors, and I recall you saying they're largely scared off by the current build system. > I am still like the Idea most to go in the direction of ant / maven, > despite its flaws. But I am not negative on SCONS either. My main point > is we need something that > > offers a better architecture and is easier to handled and maintained. > > > Also what we could try is making use of something like portage. Portage > is pretty easy to use repostory manager used by gentoo, whioch also had > a community prior to homebrew on mac. It is not very difficult to > setup. But it is build to make different build system work together. So > we could have a build repository, that builds our dependencies. We > reconstruct our monolith in smaller build libraries, like UNOcore, > OOFrame, UNOGUI, OOapp, OOpython, StarBasic, OOwizards, extentionXYZ > (Just saying something), and pick the best build system (cmake, gmake, > ant, maven, SCONS) for each library. Also we could think on incubating > Starbasic or UNO, as own Project if they become more interesting. Since > Portage is made for source build, but can also handle binaries, maybe we > could add some features that will make it easy to export towards > specific distributions, making it easy for distributors to export to > their system. BTW, portage is build on python, so it should work on all > systems we target. Sorry if this Idea is to crazy for you. It is only an > idea. > > > Maybe it is a good time now to bring this topic up in everyones mind. > > That's an interesting perspective. I never considered a build system from the view of a distribution package manager installing packages. I'll have to give it some thought. > > > All the Best > > Peter > > > Damjan
