Re: A more sane way to build - SCons, deCygwination and other hopes
Hi Pedro, On 08.12.2017 15:06, Pedro Giffuni wrote: Hello everyone! Just my $0.02 Hi After days of failing to add a few new simple features to gbuild, I've now reached my limits, and have begun experimenting with the SCons build system instead. It's starting to work. Having ported some of gbuild.mk, LinkTarget.mk and platform/freebsd.mk to SCons, as well as a module's local gbuild files, I can now compile files and (badly) link them into libraries, and clean the build. I am fine with bringing yet another build system, specially since we need this one to update Apache serf. Of course the objective should still be to remove dmake, so my request to Damjan, would be to move python ASAP to gbuild. I can understand us needing gbuild and Scons but we should be able to build SCons, and any other build system, without dmake. The objective should be to move complete. My dream would be to make the transformation automatically. For that we should focus to have the tools, and then parse the information we need from the files we have. It will take some time, thought till it realy works and we fixed all bugs from the transformation. My 2 cents how to do this.- All the best Peter - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: A more sane way to build - SCons, deCygwination and other hopes
Hello everyone! Just my $0.02 Hi After days of failing to add a few new simple features to gbuild, I've now reached my limits, and have begun experimenting with the SCons build system instead. It's starting to work. Having ported some of gbuild.mk, LinkTarget.mk and platform/freebsd.mk to SCons, as well as a module's local gbuild files, I can now compile files and (badly) link them into libraries, and clean the build. I am fine with bringing yet another build system, specially since we need this one to update Apache serf. Of course the objective should still be to remove dmake, so my request to Damjan, would be to move python ASAP to gbuild. I can understand us needing gbuild and Scons but we should be able to build SCons, and any other build system, without dmake. Regards, Pedro.
Re: A more sane way to build - SCons, deCygwination and other hopes
Hi Damjan, Do you have any reason not to use the environment class [2]? I think it does the same as the Plattformclass you created. On this overview ocument [1] you see in section 3.1 you see the architecture of Scons. I think we should try to use as much preconfigs as possble and minimize customization as much as possible. All the best Peter [1] http://scons.org/doc/production/PDF/scons-design.pdf [2] http://scons.org/doc/production/HTML/scons-user.html#chap-environments Am 07.12.2017 03:10 schrieb Damjan Jovanovic: On Sat, Dec 2, 2017 at 10:42 AM, Peter Kovacs wrote: sounds great from what you write. Lets try SCons build system. Where can I find your changes so I can help? Have you checked them into trunk? Please find a patch with my current SCons changes attached. Currently only main/fileaccess builds, on Windows and FreeBSD, and doesn't even build completely as I haven't done the "ComponentTarget" yet. You run "scons" in main/ or "scons -u" in main/fileaccess. AOO has to already be built. I have some expreience with python, which will come in handy. That's great to hear. Please let me know what you think about the structure, classes, should we use globals and soenv and SCon's Environment, etc. There is no easier time to make changes than at the beginning. Should we make a separate branch for SCons or develop in trunk? It doesn't alter any existing files so it shouldn't interfere with our existing build. Meanwhile I read Scons Documentation. Am Samstag, den 02.12.2017, 10:05 +0200 schrieb Damjan Jovanovic: Hi After days of failing to add a few new simple features to gbuild, I've now reached my limits, and have begun experimenting with the SCons build system instead. It's starting to work. Having ported some of gbuild.mk [1], LinkTarget.mk and platform/freebsd.mk [2] to SCons, as well as a module's local gbuild files, I can now compile files and (badly) link them into libraries, and clean the build. SCons is an advanced next-generation build system like gbuild, with high level declarative syntax in Python, support for multiple modules that build in parallel, header dependencies, file change detection through MD5 sums of contents instead of timestamps so rebuilds are faster, etc. It builds C, C++, Objective C, Java, Fortran, D, the sorely necessary Flex and Yacc that gbuild doesn't support. It supports tons of platforms and compilers, including OS/2. It's maintainable and usable, can print debugging info such as dependency trees, and is generally pleasant to work with. We've discussed it before on this list, but I never got to trying it until now. Virtually everything gbuild does, is already done by SCons, and often done much better. The syntax for SCons files is similar/related to gbuild's syntax, so an automated conversion from gbuild to SCons might even be possible. So far, I have defines, includes and C[XX]FLAGS working. I've structured it a bit better, with platform-specific files in classes that only provide variables to slot in higher up, instead of one giant set of globally mutable global variables like in gbuild. Linking still needs a bit of work. Windows is next on the list, as Cygwin will be the ultimate test of whether we can use it. I am very hopeful. SCons has a long history and is used by other projects, while only OO.o derivatives use gbuild. It's well documented. It supports features we need which gbuild doesn't, like library version names and flex/yacc. It's supposed to work on Windows, both inside and outside of Cygwin and could help us build without Cygwin some day. It supports many versions of Visual Studio and could help us in upgrading to a new one. We will need to add custom builders to SCons for our custom file formats like IDL, but it's just Python, not my favorite language but infinitely better than GNU make. It would help if someone could review my changes, as I am not very familiar with Python and there might be better ways to write some of the code. I'll post a patch for review after some further development. Thank you Damjan - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org Links: -- [1] http://gbuild.mk [2] http://freebsd.mk - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: A more sane way to build - SCons, deCygwination and other hopes
Globally, removing SCons should only entail: rm -rf site_scons SConstruct */SConscript Modules that get ported from gbuild to SCons would also require replacement of their main//prj/makefile.mk with a gbuild copy of that file (which is the same in all gbuild modules), and if their gbuild makefiles were deleted, they need to be restored. Modules that get ported from dmake to SCons have extensive precompiled header changes and symbol visibility changes in source code (SAL_DLLPUBLIC_EXPORT), so "svn revert" is probably the only option for them. Be more optimistic though. SCons works better than expected. And I've even made a preliminary parser/converter for gbuild's module makefiles, that can convert them into SCons build files, so a fast accurate automated conversion might be possible 😉, as least for some modules. On Thu, Dec 7, 2017 at 5:32 AM, Patricia Shanahan wrote: > If it turns out to only make things even more complicated, adding yet > another build tool, how hard would it be to remove it from trunk? > > On 12/6/2017 6:10 PM, Damjan Jovanovic wrote: > ... > >> Should we make a separate branch for SCons or develop in trunk? It doesn't >> alter any existing files so it shouldn't interfere with our existing >> build. >> > > --- > This email has been checked for viruses by AVG. > http://www.avg.com > > > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > >
Re: A more sane way to build - SCons, deCygwination and other hopes
If it turns out to only make things even more complicated, adding yet another build tool, how hard would it be to remove it from trunk? On 12/6/2017 6:10 PM, Damjan Jovanovic wrote: ... Should we make a separate branch for SCons or develop in trunk? It doesn't alter any existing files so it shouldn't interfere with our existing build. --- This email has been checked for viruses by AVG. http://www.avg.com - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: A more sane way to build - SCons, deCygwination and other hopes
On Sat, Dec 2, 2017 at 10:42 AM, Peter Kovacs wrote: > sounds great from what you write. Lets try SCons build system. > Where can I find your changes so I can help? Have you checked them into > trunk? > > Please find a patch with my current SCons changes attached. Currently only main/fileaccess builds, on Windows and FreeBSD, and doesn't even build completely as I haven't done the "ComponentTarget" yet. You run "scons" in main/ or "scons -u" in main/fileaccess. AOO has to already be built. > I have some expreience with python, which will come in handy. > > That's great to hear. Please let me know what you think about the structure, classes, should we use globals and soenv and SCon's Environment, etc. There is no easier time to make changes than at the beginning. Should we make a separate branch for SCons or develop in trunk? It doesn't alter any existing files so it shouldn't interfere with our existing build. > Meanwhile I read Scons Documentation. > > Am Samstag, den 02.12.2017, 10:05 +0200 schrieb Damjan Jovanovic: > > Hi > > > > After days of failing to add a few new simple features to gbuild, > > I've now > > reached my limits, and have begun experimenting with the SCons build > > system > > instead. > > > > It's starting to work. Having ported some of gbuild.mk, LinkTarget.mk > > and > > platform/freebsd.mk to SCons, as well as a module's local gbuild > > files, I > > can now compile files and (badly) link them into libraries, and clean > > the > > build. > > > > SCons is an advanced next-generation build system like gbuild, with > > high > > level declarative syntax in Python, support for multiple modules that > > build > > in parallel, header dependencies, file change detection through MD5 > > sums of > > contents instead of timestamps so rebuilds are faster, etc. It builds > > C, > > C++, Objective C, Java, Fortran, D, the sorely necessary Flex and > > Yacc that > > gbuild doesn't support. It supports tons of platforms and compilers, > > including OS/2. It's maintainable and usable, can print debugging > > info such > > as dependency trees, and is generally pleasant to work with. We've > > discussed it before on this list, but I never got to trying it until > > now. > > > > Virtually everything gbuild does, is already done by SCons, and often > > done > > much better. The syntax for SCons files is similar/related to > > gbuild's > > syntax, so an automated conversion from gbuild to SCons might even be > > possible. > > > > So far, I have defines, includes and C[XX]FLAGS working. I've > > structured it > > a bit better, with platform-specific files in classes that only > > provide > > variables to slot in higher up, instead of one giant set of globally > > mutable global variables like in gbuild. Linking still needs a bit of > > work. > > Windows is next on the list, as Cygwin will be the ultimate test of > > whether > > we can use it. > > > > I am very hopeful. SCons has a long history and is used by other > > projects, > > while only OO.o derivatives use gbuild. It's well documented. It > > supports > > features we need which gbuild doesn't, like library version names and > > flex/yacc. It's supposed to work on Windows, both inside and outside > > of > > Cygwin and could help us build without Cygwin some day. It supports > > many > > versions of Visual Studio and could help us in upgrading to a new > > one. We > > will need to add custom builders to SCons for our custom file formats > > like > > IDL, but it's just Python, not my favorite language but infinitely > > better > > than GNU make. > > > > It would help if someone could review my changes, as I am not very > > familiar > > with Python and there might be better ways to write some of the code. > > I'll > > post a patch for review after some further development. > > > > Thank you > > Damjan > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > > Index: SConstruct === --- SConstruct (nonexistent) +++ SConstruct (working copy) @@ -0,0 +1 @@ +SConscript('fileaccess/SConscript', variant_dir='fileaccess/build', duplicate=0) Index: site_scons/aooplatform.py === --- site_scons/aooplatform.py (nonexistent) +++ site_scons/aooplatform.py (working copy) @@ -0,0 +1,45 @@ +class Platform: +def getGUI(self): +raise Exception('Unimplemented') + +def getCOMID(self): +raise Exception('Unimplemented') + +def getCompilerDefs(self, soenv): +raise Exception('Unimplemented') + +def getCPUDefs(self, soenv): +raise Exception('Unimplemented') + +def getOSDefs(self, soenv): +raise Exception('Unimplemented') + +def getLibraryDefs(self, soenv): +raise Exception('Unimplemented') + +def getCFlags(self, soe
Re: A more sane way to build - SCons, deCygwination and other hopes
On 12/02/2017 03:05 AM, Damjan Jovanovic wrote: Hi After days of failing to add a few new simple features to gbuild, I've now reached my limits, and have begun experimenting with the SCons build system instead. It's starting to work. Having ported some of gbuild.mk, LinkTarget.mk and platform/freebsd.mk to SCons, as well as a module's local gbuild files, I can now compile files and (badly) link them into libraries, and clean the build. SCons is an advanced next-generation build system like gbuild, with high level declarative syntax in Python, support for multiple modules that build in parallel, header dependencies, file change detection through MD5 sums of contents instead of timestamps so rebuilds are faster, etc. It builds C, C++, Objective C, Java, Fortran, D, the sorely necessary Flex and Yacc that gbuild doesn't support. It supports tons of platforms and compilers, including OS/2. It's maintainable and usable, can print debugging info such as dependency trees, and is generally pleasant to work with. We've discussed it before on this list, but I never got to trying it until now. Virtually everything gbuild does, is already done by SCons, and often done much better. The syntax for SCons files is similar/related to gbuild's syntax, so an automated conversion from gbuild to SCons might even be possible. So far, I have defines, includes and C[XX]FLAGS working. I've structured it a bit better, with platform-specific files in classes that only provide variables to slot in higher up, instead of one giant set of globally mutable global variables like in gbuild. Linking still needs a bit of work. Windows is next on the list, as Cygwin will be the ultimate test of whether we can use it. I am very hopeful. SCons has a long history and is used by other projects, while only OO.o derivatives use gbuild. It's well documented. It supports features we need which gbuild doesn't, like library version names and flex/yacc. It's supposed to work on Windows, both inside and outside of Cygwin and could help us build without Cygwin some day. It supports many versions of Visual Studio and could help us in upgrading to a new one. We will need to add custom builders to SCons for our custom file formats like IDL, but it's just Python, not my favorite language but infinitely better than GNU make. It would help if someone could review my changes, as I am not very familiar with Python and there might be better ways to write some of the code. I'll post a patch for review after some further development. Thank you Damjan Hi Damjan, Please don't take this as a suggestion. I admire your dedication to finding a solution to our build tool issues and all your work. This is only curiosity. Have you looked at Gradle at all? It uses Apache Groovy for scripting rather than Python and may be a more familiar syntax. I use it almost exclusively now for my other (much much smaller Java and Groovy) projects. I know it's used for Java, and C/C++ but not sure of the pros/cons vs. the others you have looked into. Best regards, Carl - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: A more sane way to build - SCons, deCygwination and other hopes
On 2 Dec, Damjan Jovanovic wrote: > * It already broke certain mixtures of build settings, eg. I think you > can't both debug build and use precompiled headers on Windows, CFLAGS gets > lost somewhere... I figured out that problem and discovered that when using precompiled headers with Visual C++, the optimization flags need to be consistent between the precompiled headers and when the source files are compiled. After getting past that, I found that when debugging enabled the argument to -Fd must also be consistent between compiling the headers and compiling the sources. The first problem there is that when compiling the sources the value of $(PDBFILE) is somehow getting lost. I'm not sure what is going wrong there, but I have a workaround. The next problem is that when building a module with multiple libraries, the value of $(PDBFILE) has the library name built in as in: $W/LinkTarget/pdb/Library/.lib.pdb That means that the headers need to be compiled separately for each library with the matching value of $(PDBFILE) and the resulting compiled headers need to be stashed in a separate, per-library place instead of $W/PrecompiledHeader/debug/precompiled_.hxx.{pch,pch.obj} This is pretty baked into the the gbuild framework due to the use of globals. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: A more sane way to build - SCons, deCygwination and other hopes
On Sunday, December 3, 2017, Don Lewis wrote: > On 2 Dec, Damjan Jovanovic wrote: > > On Sat, Dec 2, 2017 at 4:19 PM, Jim Jagielski wrote: > > > >> Playing devils advocate, does it make sense to introduce > >> Yet Another Build System at this stage? > >> > >> > > I anticipated this question. > > > > Firstly, we don't only have dmake and gbuild as our build systems. We > also > > use Ant, meta-build tools like build.pl and co, Microsoft's nmake for > > main/icu on Windows, and probably more. The existing number of tools > > doesn't negatively affect development, so why should 1 more? > > > > Secondly SCons can replace ./configure, so in all all-SCons world we > would > > eliminate 3 tools, not just 2. > > > > As for "sense . .. at this stage", we've hit several walls with gbuild at > > this stage: > > * It can't version libraries in the form of reg3.dll vs reg.so linking to > > reg.so.3 on *nix. Most of gbuild was written with the assumption > libraries > > on *nix always end with .so. Even when we dangerously weaken those > > assumptions, and badly hack it, it doesn't deliver the link... > > Other than for the benefit of extensions, I don't see much point in > versioning the libraries because they are otherwise private. If add > versioning so that it is more obvious that an old extension won't work > with a new version of AOO, are we disiplined enough to do the > appropriate version bumps? > > > * It already broke certain mixtures of build settings, eg. I think you > > can't both debug build and use precompiled headers on Windows, CFLAGS > gets > > lost somewhere... > > That should be fixable, but ... > > > * Nobody knows gbuild. The syntax is atrocious. It uses obscure features > of > > GNU make. We can't debug it. It takes days of work to investigate/fix any > > problem with it, work that could be better spent on a this vast project > > with few development resources. > > Agreed 1000% here. > > If you are doing a build with bundled python, how do you bootstrap? If > you are on Windows and don't have python, how do you run the SCons > equivalent of configure and then use SCons to build python? > > I am currently doing it by installing Python natively in Windows, installing SCons there through pip, and then calling that scons.bat from Cygwin. And, beyond my wildest expectations, SCons in this setup successfully compiled and linked a module, both inside Cygwin AND OUTSIDE IT!!! :) :) > And a more recent question near and dear to my heart, how easy is it to > do per-target optimization flag overrides? > > C[XX]FLAGS are specified to SCons like all other settings, as arrays of strings. You can specify common settings in the environment object and can add to those or replace them on individual SharedObjects. > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > > Damjan
Re: A more sane way to build - SCons, deCygwination and other hopes
On 02/12/2017 Jim Jagielski wrote: What I don't want is some hybrid monstrosity like we have now. Nor do I want work on the build system to hold off release of 4.2.0. This is surely a good point. Actually, the wide delay between 4.1.0 and the future 4.2.0 is due in big part to build changes. Most welcome, but also time consuming. There is a reason, though, that makes Damjan's current effort worth investigating in all cases: we had to put a large patch (for a bugfix involving work with remote files) on hold for 4.1.2 since that would have required updating serf, which in turn would have implied that we added support for SCons as they have switched to it for their recent releases. I can dig up the issue if you need, just ask if interested. Having a way to build SCons-based packages would already be a step forward. And yes, it would be "just another tool" in this case, but with so many dependencies we must be able to integrate many build systems. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: A more sane way to build - SCons, deCygwination and other hopes
On 03.12.2017 01:57, Don Lewis wrote: On 2 Dec, Damjan Jovanovic wrote: * Nobody knows gbuild. The syntax is atrocious. It uses obscure features of GNU make. We can't debug it. It takes days of work to investigate/fix any problem with it, work that could be better spent on a this vast project with few development resources. Agreed 1000% here. If you are doing a build with bundled python, how do you bootstrap? If you are on Windows and don't have python, how do you run the SCons equivalent of configure and then use SCons to build python? Today you need perl. So we replace one language with another. I think the benefit is that Scons is a generic Buildsystem that is maintained by a team. So creating a valid build environment may be much simpler then the version we have today. But this depends how we use the tool. Configure and bootstrap is up to us. We could stick with the current process. (Replace only the build command) We could include the current process within Scons. Or we could integrate both into Scons using Scons provided tools. While I am not sure how to do the last step. What I have seen if we integrate it into Scon, we can define our own Flags to control the behaviour. (Switch Bootstrap on, or not) And a more recent question near and dear to my heart, how easy is it to do per-target optimization flag overrides? Scons thinks in build Environments, which are Enviroment Objects. Each Environment contains build flags. An Enviroment could Fetch Values from another enviroment, but we can also expand values, replace values or clone them. There are also ways to Append and to Prepend values (with the option do do this unique). An Environment can be created having default values. We can define Issue handling on environment level. If we know combinations do not work or something is missing. We can also define multiple Enviroments. However a build config can only be associated with one build environment. I hope this gives an Idea what posilities we have with Scons. How we design our build process is up to us. I would think that we have one global environment that feeds from Templates like Debug and release. Each Module has then a specific own Environment which feeds from the global ones. HTH Peter - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: A more sane way to build - SCons, deCygwination and other hopes
On 2 Dec, Damjan Jovanovic wrote: > On Sat, Dec 2, 2017 at 4:19 PM, Jim Jagielski wrote: > >> Playing devils advocate, does it make sense to introduce >> Yet Another Build System at this stage? >> >> > I anticipated this question. > > Firstly, we don't only have dmake and gbuild as our build systems. We also > use Ant, meta-build tools like build.pl and co, Microsoft's nmake for > main/icu on Windows, and probably more. The existing number of tools > doesn't negatively affect development, so why should 1 more? > > Secondly SCons can replace ./configure, so in all all-SCons world we would > eliminate 3 tools, not just 2. > > As for "sense . .. at this stage", we've hit several walls with gbuild at > this stage: > * It can't version libraries in the form of reg3.dll vs reg.so linking to > reg.so.3 on *nix. Most of gbuild was written with the assumption libraries > on *nix always end with .so. Even when we dangerously weaken those > assumptions, and badly hack it, it doesn't deliver the link... Other than for the benefit of extensions, I don't see much point in versioning the libraries because they are otherwise private. If add versioning so that it is more obvious that an old extension won't work with a new version of AOO, are we disiplined enough to do the appropriate version bumps? > * It already broke certain mixtures of build settings, eg. I think you > can't both debug build and use precompiled headers on Windows, CFLAGS gets > lost somewhere... That should be fixable, but ... > * Nobody knows gbuild. The syntax is atrocious. It uses obscure features of > GNU make. We can't debug it. It takes days of work to investigate/fix any > problem with it, work that could be better spent on a this vast project > with few development resources. Agreed 1000% here. If you are doing a build with bundled python, how do you bootstrap? If you are on Windows and don't have python, how do you run the SCons equivalent of configure and then use SCons to build python? And a more recent question near and dear to my heart, how easy is it to do per-target optimization flag overrides? - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: A more sane way to build - SCons, deCygwination and other hopes
Am 02.12.2017 um 23:13 schrieb Jim Jagielski: On Dec 2, 2017, at 1:59 PM, Damjan Jovanovic wrote: On Sat, Dec 2, 2017 at 4:19 PM, Jim Jagielski wrote: Playing devils advocate, does it make sense to introduce Yet Another Build System at this stage? I anticipated this question. :) Secondly SCons can replace ./configure, so in all all-SCons world we would eliminate 3 tools, not just 2. ./configure seems to work fine. * Nobody knows gbuild. And more people know SCons?? :) My point is that likely more people know make and gmake and its obscure features than SCons. What I don't want is some hybrid monstrosity like we have now. Nor do I want work on the build system to hold off release of 4.2.0. relating to the last sentence: For this there is the fantastic invention of branches. ;-) OK, seriously: At the moment we are talking more about a 4.2.0 release than all other posts in the past together. Therefore we should think of when the best time point is for creating a new 4.2.0 branch. IMHO it is coming really closer. Then we can go on on Trunk with improving the build system without any effects for 4.2.0. My 2ct. Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: A more sane way to build - SCons, deCygwination and other hopes
> On Dec 2, 2017, at 1:59 PM, Damjan Jovanovic wrote: > > On Sat, Dec 2, 2017 at 4:19 PM, Jim Jagielski wrote: > >> Playing devils advocate, does it make sense to introduce >> Yet Another Build System at this stage? >> >> > I anticipated this question. :) > > Secondly SCons can replace ./configure, so in all all-SCons world we would > eliminate 3 tools, not just 2. ./configure seems to work fine. > > * Nobody knows gbuild. And more people know SCons?? :) My point is that likely more people know make and gmake and its obscure features than SCons. What I don't want is some hybrid monstrosity like we have now. Nor do I want work on the build system to hold off release of 4.2.0. Just my own 2c and all the above IMHO - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: A more sane way to build - SCons, deCygwination and other hopes
On Sat, Dec 2, 2017 at 4:19 PM, Jim Jagielski wrote: > Playing devils advocate, does it make sense to introduce > Yet Another Build System at this stage? > > I anticipated this question. Firstly, we don't only have dmake and gbuild as our build systems. We also use Ant, meta-build tools like build.pl and co, Microsoft's nmake for main/icu on Windows, and probably more. The existing number of tools doesn't negatively affect development, so why should 1 more? Secondly SCons can replace ./configure, so in all all-SCons world we would eliminate 3 tools, not just 2. As for "sense . .. at this stage", we've hit several walls with gbuild at this stage: * It can't version libraries in the form of reg3.dll vs reg.so linking to reg.so.3 on *nix. Most of gbuild was written with the assumption libraries on *nix always end with .so. Even when we dangerously weaken those assumptions, and badly hack it, it doesn't deliver the link... * It already broke certain mixtures of build settings, eg. I think you can't both debug build and use precompiled headers on Windows, CFLAGS gets lost somewhere... * Nobody knows gbuild. The syntax is atrocious. It uses obscure features of GNU make. We can't debug it. It takes days of work to investigate/fix any problem with it, work that could be better spent on a this vast project with few development resources. > Also, there are a few projects that I know of that > use SCons. In general, one of the most popular common > threads related to them are "Why the hell are you using SCons?" :) > > I'd like to see those discussions. SCons as opposed to what? Damjan
Re: A more sane way to build - SCons, deCygwination and other hopes
Am Samstag, den 02.12.2017, 09:19 -0500 schrieb Jim Jagielski: > Playing devils advocate, does it make sense to introduce > Yet Another Build System at this stage? I see it as for the search for the future build system. There is always the discussion popping up what to use. Gbuild seem to make some troubles. We have looked into Maven with no good result. So far satisfactory outcome. So you as the release team still use the old one with the known difficulties. I think we should give it a try. Well buts that me, as a noob I want to try always all options and then decide where my favours are. > > Also, there are a few projects that I know of that > use SCons. In general, one of the most popular common > threads related to them are "Why the hell are you using SCons?" :) Do they bash or is there some serious arguments behind that?- I am always interested in negative opinion as long as they have substance. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: A more sane way to build - SCons, deCygwination and other hopes
Playing devils advocate, does it make sense to introduce Yet Another Build System at this stage? Also, there are a few projects that I know of that use SCons. In general, one of the most popular common threads related to them are "Why the hell are you using SCons?" :) > On Dec 2, 2017, at 3:05 AM, Damjan Jovanovic wrote: > > Hi > > After days of failing to add a few new simple features to gbuild, I've now > reached my limits, and have begun experimenting with the SCons build system > instead. > > It's starting to work. Having ported some of gbuild.mk, LinkTarget.mk and > platform/freebsd.mk to SCons, as well as a module's local gbuild files, I > can now compile files and (badly) link them into libraries, and clean the > build. > > SCons is an advanced next-generation build system like gbuild, with high > level declarative syntax in Python, support for multiple modules that build > in parallel, header dependencies, file change detection through MD5 sums of > contents instead of timestamps so rebuilds are faster, etc. It builds C, > C++, Objective C, Java, Fortran, D, the sorely necessary Flex and Yacc that > gbuild doesn't support. It supports tons of platforms and compilers, > including OS/2. It's maintainable and usable, can print debugging info such > as dependency trees, and is generally pleasant to work with. We've > discussed it before on this list, but I never got to trying it until now. > > Virtually everything gbuild does, is already done by SCons, and often done > much better. The syntax for SCons files is similar/related to gbuild's > syntax, so an automated conversion from gbuild to SCons might even be > possible. > > So far, I have defines, includes and C[XX]FLAGS working. I've structured it > a bit better, with platform-specific files in classes that only provide > variables to slot in higher up, instead of one giant set of globally > mutable global variables like in gbuild. Linking still needs a bit of work. > Windows is next on the list, as Cygwin will be the ultimate test of whether > we can use it. > > I am very hopeful. SCons has a long history and is used by other projects, > while only OO.o derivatives use gbuild. It's well documented. It supports > features we need which gbuild doesn't, like library version names and > flex/yacc. It's supposed to work on Windows, both inside and outside of > Cygwin and could help us build without Cygwin some day. It supports many > versions of Visual Studio and could help us in upgrading to a new one. We > will need to add custom builders to SCons for our custom file formats like > IDL, but it's just Python, not my favorite language but infinitely better > than GNU make. > > It would help if someone could review my changes, as I am not very familiar > with Python and there might be better ways to write some of the code. I'll > post a patch for review after some further development. > > Thank you > Damjan - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: A more sane way to build - SCons, deCygwination and other hopes
sounds great from what you write. Lets try SCons build system. Where can I find your changes so I can help? Have you checked them into trunk? I have some expreience with python, which will come in handy. Meanwhile I read Scons Documentation. Am Samstag, den 02.12.2017, 10:05 +0200 schrieb Damjan Jovanovic: > Hi > > After days of failing to add a few new simple features to gbuild, > I've now > reached my limits, and have begun experimenting with the SCons build > system > instead. > > It's starting to work. Having ported some of gbuild.mk, LinkTarget.mk > and > platform/freebsd.mk to SCons, as well as a module's local gbuild > files, I > can now compile files and (badly) link them into libraries, and clean > the > build. > > SCons is an advanced next-generation build system like gbuild, with > high > level declarative syntax in Python, support for multiple modules that > build > in parallel, header dependencies, file change detection through MD5 > sums of > contents instead of timestamps so rebuilds are faster, etc. It builds > C, > C++, Objective C, Java, Fortran, D, the sorely necessary Flex and > Yacc that > gbuild doesn't support. It supports tons of platforms and compilers, > including OS/2. It's maintainable and usable, can print debugging > info such > as dependency trees, and is generally pleasant to work with. We've > discussed it before on this list, but I never got to trying it until > now. > > Virtually everything gbuild does, is already done by SCons, and often > done > much better. The syntax for SCons files is similar/related to > gbuild's > syntax, so an automated conversion from gbuild to SCons might even be > possible. > > So far, I have defines, includes and C[XX]FLAGS working. I've > structured it > a bit better, with platform-specific files in classes that only > provide > variables to slot in higher up, instead of one giant set of globally > mutable global variables like in gbuild. Linking still needs a bit of > work. > Windows is next on the list, as Cygwin will be the ultimate test of > whether > we can use it. > > I am very hopeful. SCons has a long history and is used by other > projects, > while only OO.o derivatives use gbuild. It's well documented. It > supports > features we need which gbuild doesn't, like library version names and > flex/yacc. It's supposed to work on Windows, both inside and outside > of > Cygwin and could help us build without Cygwin some day. It supports > many > versions of Visual Studio and could help us in upgrading to a new > one. We > will need to add custom builders to SCons for our custom file formats > like > IDL, but it's just Python, not my favorite language but infinitely > better > than GNU make. > > It would help if someone could review my changes, as I am not very > familiar > with Python and there might be better ways to write some of the code. > I'll > post a patch for review after some further development. > > Thank you > Damjan - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
A more sane way to build - SCons, deCygwination and other hopes
Hi After days of failing to add a few new simple features to gbuild, I've now reached my limits, and have begun experimenting with the SCons build system instead. It's starting to work. Having ported some of gbuild.mk, LinkTarget.mk and platform/freebsd.mk to SCons, as well as a module's local gbuild files, I can now compile files and (badly) link them into libraries, and clean the build. SCons is an advanced next-generation build system like gbuild, with high level declarative syntax in Python, support for multiple modules that build in parallel, header dependencies, file change detection through MD5 sums of contents instead of timestamps so rebuilds are faster, etc. It builds C, C++, Objective C, Java, Fortran, D, the sorely necessary Flex and Yacc that gbuild doesn't support. It supports tons of platforms and compilers, including OS/2. It's maintainable and usable, can print debugging info such as dependency trees, and is generally pleasant to work with. We've discussed it before on this list, but I never got to trying it until now. Virtually everything gbuild does, is already done by SCons, and often done much better. The syntax for SCons files is similar/related to gbuild's syntax, so an automated conversion from gbuild to SCons might even be possible. So far, I have defines, includes and C[XX]FLAGS working. I've structured it a bit better, with platform-specific files in classes that only provide variables to slot in higher up, instead of one giant set of globally mutable global variables like in gbuild. Linking still needs a bit of work. Windows is next on the list, as Cygwin will be the ultimate test of whether we can use it. I am very hopeful. SCons has a long history and is used by other projects, while only OO.o derivatives use gbuild. It's well documented. It supports features we need which gbuild doesn't, like library version names and flex/yacc. It's supposed to work on Windows, both inside and outside of Cygwin and could help us build without Cygwin some day. It supports many versions of Visual Studio and could help us in upgrading to a new one. We will need to add custom builders to SCons for our custom file formats like IDL, but it's just Python, not my favorite language but infinitely better than GNU make. It would help if someone could review my changes, as I am not very familiar with Python and there might be better ways to write some of the code. I'll post a patch for review after some further development. Thank you Damjan