[cmake-developers] CMake daemon for user tools
Milian Wolff
mail at milianw.de
Tue Jan 12 22:20:14 UTC 2016
On Montag, 11. Januar 2016 23:22:23 CET Alexander Neundorf wrote:
> On Monday, January 11, 2016 15:59:35 Aleix Pol wrote:
> ...
>
> > Hi Stephen, everyone,
> > I've already discussed this in private with you. I think it's a good
> > idea and I'd like to make sure we can benefit from this.
> >
> > I'm unsure of the feasibility of the project though.
>
> you maybe remember that my main issue with your patch last year was that
> it's not a "generator", while it does what generators are for.
> After talking with Milian a bit several week ago, I understood that an
> important reason why the kdevelop team does not want a generator is that
> there is only one generator per build-tree, i.e. the user has to decide
> beforehand which IDE project files he wants.
> With the branch I created on github a few days ago, which I announced here
> too, I changed the way the extra generators are activated: they are not
> activated like the main generators anymore, but can be turned on and off
> using normal cmake cache options, so multiple generators (e.g. the generic
> json generator and let's say the Eclipse generator) can both be turned on,
> initially or later on. I think this should solve this problem.
> The work there
> (https://github.com/neundorf/CMake/tree/RefactorExtraGeneratorsExperimental
> ) is not ready for inclusing, but it shows how it can be done and can serve
> as a starting point/inspiration.
>
> Stephens big approach will need some time until it is ready, while such a
> (relatively) simple thing can probably be done within one release cycle (but
> I don't have the time to do it).
>
> I don't know what the others here think about adding your json-approach or
> not.
I don't think I'll have the required time to help here either, but I agree
with your reasoning: Your patch is the potentially quickest to get something
done. But it only fixes the usability issue of generators, it does not come
with a useable generator which we'll still need to write.
Stephens approach is far more sophisticated, and touches far more than
generators can ever achieve. All of this is something that we need in an IDE:
- edit helpers
- proper updates when a file changes
- support for "live editing", i.e. updating the info from an unsaved editor
buffer
- code completion
- ...
Yes, this list is long. But we need it. Some thing are extremely important,
others less so. I really hope that this project proceeds and finds helping
hands.
Btw, while I haven't looked into it, there is at least one positive thing to
say about QBS: It's IDE integration. Maybe that is also a place to look for
inspiration?
Cheers
--
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20160112/2229a92f/attachment.sig>
More information about the KDevelop-devel
mailing list