On Fri, Oct 5, 2018 at 8:45 PM George Karalis <[email protected]> wrote:
> > Hello everyone, > > Hi, welcome :) > Since am new to the project and working on understanding the build process > this past > week, I agree with Damjan that the build system needs that overhaul. I > also agree that > a MSVC upgrade and a 64-bit windows build, is of high priority. Changing > the build > system will take months. > > As of the MSVC upgrade I have figured out how the whole configure works > and I ‘m > now integrating MSVC++ 14.15 to oowintool script, and trying to integrate > Windows 10 > SDK to the configure pipeline as well. After that I 'll try to figure out > the build errors and > fix everything to a successful build. If and when the upgrade completes, > we should also > investigate implementing targets - if there are none - for the build tool. > > e.g. To compile for windows XP, we need the Windows XP platform toolset, > which installs > Windows 7.1 SDK, among other things and can build for Windows XP using > MSCV++ > 2017 and run something like: build —all —target=“winXP”. > > Don't do that. Once the port to gbuild is complete, the "build" command will disappear. Also the MSVC information is already stored in environment variables from set_soenv(.in) -> winenv.set.sh like COM, COMID, CCVER, CCNUMVER, etc. > Since I am unfamiliar with UNO, I can’t provide any points there, but I > agree with that > separation of concerns, to keep only office functionality at the core of > the project. Also > another future idea would be to split - I don’t know if it's possible - > each application, > Writer, Calc, Impress etc. in its own separate module, so they can build > independently > and, maybe?, debug easier, since someone can work on features on only the > app he/she > wants. > > As for the build system, after some research, I concluded on three modern > build pipelines, > CMake, SCons and Meson. Personally, I am in favour of CMake, with the only > argument > that it’s backed by many large companies and that provides a safety for > the future. The two > systems are almost identical, SCons is more extensible due to Python, but > all in all > it’s just a weight of each build system's pros and cons. Also, how KDE > switched <https://lwn.net/Articles/188693/> > to CMake <https://lwn.net/Articles/188693/> was an interesting read. But, > I think Damjan knows better about the project, so > we can have an open discussion about which build system is better for > OpenOffice. > > CMake was already investigated by the original OOo team and found to be lacking. Unlike CMake's module-at-a-time approach, gbuild and SCons take the better approach of building a global project-wide list of dependencies for each and every file, which is deterministic and always correct (unlike the underspecified/overspecified module dependencies which give inconsistent build results), and then optimally parallelizing the build at a file level, instead of the artificial walls between modules limiting build speed. > I think that for now we should focus on upgrading our tools, new > compilers, SDKs, because > it's easier, it has been a week and I have done some progress already, and > it will ease > development a little, but ultimately changing to a modern build system can > have tremendous > potential for the project, modern build systems integrate perfect with > Visual Studio, > Xcode, working on an IDE it’s always nice 🙂. > > Agreed :). > Kind regards, > George > > Regards Damjan
