Discussion on "add to new target" wizard for CMake
Milian Wolff
mail at milianw.de
Fri May 14 09:07:56 UTC 2010
Andreas Pakulat, 14.05.2010:
> On 13.05.10 23:37:12, Milian Wolff wrote:
> > please read: https://bugs.kde.org/show_bug.cgi?id=237535
> >
> > I'd be interested in more feedback, what do you guys think? Why would
> > this be a bad idea to take this burden off a developer?
> >
> > And having different templates for "add to new target" would imo still
> > better than designated wizards for "new app", "new unit test", "new
> > class", "new library", ... or what do you think?
>
> I actually misunderstood and misremembered the problem. I guess having a
> buildsystem-page (provided by the buildsystem-manager of the project) in
> the create-class-wizard that allows to create a new target if you
> selected create-class on a non-target item would be ok.
>
> For cmake this could allow to select from a list of types and ask for a
> target-name. Then it'll add the relevant add_executable/add_library/...
> line at the end of the cmake file and on the last page the change could
> be reviewed just as if it was added to an existing target.
>
> The thing is that we need to draw a line somewhere wrt. the number of
> "types" above. In particular do we allow to choose between static and
> shared libs? Do we allow to select between doing a macosx-framework or
> dylib? Do we allow to choose between a windows-app or a
> windows-console-app? Those are flags to add_executable/add_library and
> IMHO we shouldn't support any of them, just the basic types that exist.
> Else we'll sooner or later end in a maintainenance hell as users keep
> asking to add <some special flag-combo>...
I think just adding a flag would be better solved by code completion. I.e.
always insert the "prestine" state for a library and if the user wants to make
it a static lib he should request code completion at the right place and
insert the flag.
Which otoh would require KDev features in the edit/review katepart, which
afaik is not working, is it? ;-)
Anyways, as long as we have something like "executable, library, unit test"
I'm fine :P
> > How would we add something like "qt unit test", "kde unit test" only to
> > projects that actually use that? Has CMake the knowledge about that?
>
> CMake should know when kde4_add_unit_test is available (IIRC there's no
> macro for qt4 unit-tests). Its a macro only available if you
> find_package(KDE4).
>
> I'm still not 100% sure wether this is really needed. Adding a new
> target is not something you do that often, except for unit-tests maybe.
> Unless of course you start several new projects/hour or your project is
> still very young :) But as I said above, having an extra page supplied
> by the buildsystem with a list of the 5 standard target-types would be
> ok for me (if somebody else implements it :P)
I do it often enough to get annoyed by the lack of support kdevelop gives me
;-)
I could of course simply create a CMake snippet for my own usecase now but
well, I'm still thinking the other approach would be nicer.
--
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: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20100514/8b054d26/attachment.sig>
More information about the KDevelop-devel
mailing list