Given how I've only developed on FreeBSD so far, anything Windows is probably at negative infinity :).
Do you have some example modules with that symbols problem, or at least know whether they are gbuild or dmake modules? On Sat, Jul 4, 2020 at 9:13 PM Patricia Shanahan <p...@acm.org> wrote: > 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 > >
