openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damjan Jovanovic <dam...@apache.org>
Subject Re: Other build ideas (was: Re: Windows Build Environment futures
Date Sat, 06 Oct 2018 05:33:45 GMT
On Fri, Oct 5, 2018 at 8:45 PM George Karalis <thorbust@gmail.com> 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message