Budgeting & investing in features ...

[Bjoern Michaelsen]

Hi,

On Sat, Dec 10, 2016 at 10:49:14AM -0500, Ashod Nakashian wrote:
> I guess the issue here is that one needs a full-build before generating the
> project files. 

This used to be the case, but since gbuildtojson exists, you do NOT need a full
build anymore to create the solution files. "./autogen.sh && make
vs2013-ide-integration" on a virgin clone should work and not need a full
build.

> The suggestion is to generate the ide files for the most common ones after
> full and successful builds, and automatically commit them (if they have
> changed). If we don't want to pollute the LO repo (and avoid potentially
> nasty recursive build triggers etc.) then these files could go into a
> separate repo that is submodule'd into LO.git.

The core issue with this is that the solution files include all kind of
configuration dependant stuff. So for this to work we essentially need to nail
down windows to one config, that is:
- a hardcoded set of ./autogen.sh-switches
- a fixed setup for the usual paths: SRCDIR, BUILDDIR, cygwin-dir etc.

> Should be straightforward, in terms of scripting, except maybe to consider
> how these ide files would be organized, located etc. Scattering them in
> each directory won't work with submodule, so they'd have to be generated in
> a single 'ide' directory. Otherwise, they can stay where they are, and get
> committed to the LO.git repo, which (as said) might be suboptimal.

Putting solutions in one dir away for the source should work for MSVS. It wont
for e.g. kdevelop, which needs files directly in the source file dirs.

> P.S. VS, the most common IDE I imagine, upgrades project files
> automatically. So we only need to generate them for the oldest supported
> version.

As said above, there is no full build needed for generating IDE integration
output anymore. "make gbuildtojson" takes a few seconds and translating that to
IDE solutions is currently fast for all IDEs. So generating _all_ IDE solutions
should be trivial computing-ressourcewise. The hard part is creating the
canonical hardcoded config for this output to be universally usable[1].

OTOH, as said above, you dont need a full build anymore to generate a solution
file. It might even simpler and better to:

1/ Bake this into LODE or whatever is used for initial setup on various platforms
2/ Update docs (best with videos too) to make the initial setup a walk in the parc
   (Because if e.g. you think one needs a full build for vs2013-ide-integration -- who
   can blame newcomers to be confused?)
3/ Once we have the simplified initial setup on Windows, lets scream about it far
   and wide in blogs, planets and social media to kill the outdated cargo-cult knowledge.
4/ Regulary (daily/weekly) run and test the IDE integrations to make sure we
   dont regress and that our docs stay up-to-date.

because I fear, even if you define a "canonical build setup" that we create
solution files for, it will be just as errorprone for newcomers to exactly recreate it
and you will trade one set of pain for another.

Best,

Bjoern


[1] Which is unlikely to succeed for IDEs used on multiple platforms, e.g.
    Eclipse.