Re: Building LibreOffice on Windows

On Mon, Feb 20, 2012 at 09:44:50AM +0000, Michael Meeks wrote:
> On Mon, 2012-02-20 at 18:22 +1030, Josh Heidenreich wrote:
> > Okay so it might be nuts, but has anyone tried creating a native VS
> > solution/projects, which ruins inside the ide? Could one be created
> > cmake style perhaps?
>
>       Ruins ? :-) I suspect that, unless this can be compiled from the
> gnumake information - and (I guess) this is not utterly impractical,
> given the high-level gnumake descriptions I suspect; that this would be
> a ton of work to maintain - particularly since MS change their VS
> project format fairly regularly IIRC.

Well, just like we have backends for Linux, OS X and Windows/Cygwin in
solenv/gbuild/platform, we could have another one that instead of building in a
cygwin shell creates the MSBuild files and kicks off a build with those. That
file could also be used in MSVC to build from the IDE.

However:
- You cant edit it from the IDE as it is generated (or you would have to
  duplicate your changes in gbuild later)
- Building C++ libraries might be reasonably easy to implement, but all our
  custom tooling will be a pain (l10n, SDFs etc.)

IMHO it would be an unreasonably high effort to get this done for a complete
build and because the generated MSBuild files are readonly (i.e. if you add a
C++ file you would need to edit gbuild files again) and one would need to be
careful to regenerate them after changes the gain is minimal.

I wouldnt oppose someone doing it (actually I think it would be a cute hack),
but rationally I think it is rarely worth it. The only scenario where it would
be useful, is some native windowshacker just working on one lib. Then he could
generate a MSBuild description for it, work on it and only in the end would
need to translate his build changes (added source files etc.) back to gbuild,
while being able to using his trusted and known MSVC IDE for the rest.

Best,

Bjoern

P.S.: Note that even then MSVC would be pushed to its limits: code complete for
a library like libsw would suffer hard from the things that needed to be parsed
from all the includes. IIRC from the tests once made on a very powerful machine
it still works, but it would be too slow to most being used to faster editing
with vim and opengrok. And yeah: Netbeans is even slower -- once it did a gc
every second it knocked itself out quite effectively.