scripting is a dmake module with no symbols package is a gbuild module with symbols
So yes, as we move off dmake, more and more modules should have working debug symbols. This is the case on *nix too, where dmake doesn't provide full paths to filenames, breaking debugging. On Sat, Jul 4, 2020 at 9:35 PM Patricia Shanahan <p...@acm.org> wrote: > On 7/4/2020 12:24 PM, Damjan Jovanovic wrote: > > 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? > > c:\OpenOfficeDev\openoffice\main\scripting\source\protocolhandler\scripthandler.cxx > > does not have symbols. > > c:\OpenOfficeDev\openoffice\main\package\source\xstor\xstorage.cxx does > have symbols generated. > > > > 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 > >> > >> > > > > -- > 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 > >
