<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 8, 2016 at 4:58 AM, Jan Iversen <span dir="ltr"><<a href="mailto:jani@documentfoundation.org" target="_blank">jani@documentfoundation.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The new “gbuildtojson” that Bjoern has made, is a step in the right direction, but we are still far from a goal, where a contributor clone the repo and open his preferred IDE to start working.<br><div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div><div>I guess the issue here is that one needs a full-build before generating the project files. Couldn't we possibly automate this? It's not ideal, I understand, but if it attracts more contributors then we all win.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>-Ash</div><div><br></div><div>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.</div></div></div></div>