By default, qt-creator builds with all stable plugins (except, for some strange reason, designer plugin). However, it is very easy to control this behaviour, since a list of enabled plugins can be found at src/plugins/plugins.pro Reproducible: Always
Created attachment 185586 [details] Modified ebuild I took care to enable all plugins except designer by default, so with no configuration (i.e. no USE or package.use modifications) it works just as old ebuild.
Thanks for that ebuild. My first concern is what do you mean by "not installing designer" plugin. I am able to design Ui forms perfectly. Do you mean something else? The other thing is , do we really need to have so many use flags? In my head qt-creator is a full-feature IDE so I wouldnt want it with half-of-its-features installed. I am sure that 99% of users will want it full.
Well, if editing Ui from qtcreator works on your end, i'm sort of lost there, since both ebuild and manual build failed to build designer support by default, since it's not listed in SUBDIRS -- most likely because someone @ qt software forgot to add it or something. As a result, qtcreator opens *.ui files with built-in text editor. Maybe I overlooked some autodetection which fails on my end though. I'll double-check that. As to overwhelming number of USE flags, I figured that I want to compile out perforce support. Some people might want to remove fakevim or cmake manager (at least, I can imagne that). Main reasonong here is to allow user to choose, after all it's what free software about. Another subtle reason is the fact that some plugins actually do have runtime dependances not listed in ebuild (yet). I thought about it, but turned lazy all of a sudden, so it isn't there :) To illustrate my point, debugger plugin relies on sys-devel/gdb, svn on dev-util/subversion, git on dev-util/git, and so on. A failure to satisfy this defendances does not really break anything, but it does not allow related plugins to be used as well, so why bother building them then? On the other hand, you might be right in a sense that editors and managers are best left compiled in, so it might be better to trim down IUSE list a bit.
(In addition to comment #3) Yes, i sort of overlooked a wierd autodetection there. It checks if qt is installed version (prebuilt release) or built from source with exists($$(QTDIR)/.qmake.cache). First of, my QTDIR env variable is empty. But even if it wasn't, there's no .qmake.cache there (most likely since it was removed at some point of cleanup). BTW, I failed to notice absence of resourceeditor plugin, which also uses this strange .cache thing. I'm really not shure if it's a bug, or a feature.
Yes, I am able to edit ui files via designer. However I ve heard it before that users had the same issues with ui files. I am not sure what is going on there so far. I assume that we could add git,svn and gdb use flags there. A reasonable number of use flags is ok by me. But I wouldnt want to have +5 use flags in order to build every basic component separately. I wouldn't add cmake use flag cause people are developing different projects from time to time so it wouldn't be comfortable from our side to make them re-install the program in order to get a basic feature. However I agree that there are many ways to split/improve the build system so I am open to new ideas. I ll try to come up with a new ebuild with git,svn,gdb use flags for now :)
(In reply to comment #5) > I wouldn't add cmake use flag cause people are developing different projects > from time to time so it wouldn't be comfortable from our side to make them > re-install the program in order to get a basic feature. IMO it's better to have cmake use-flag, and make it enabled by default. Then we still have configurability and users will have cmake support unless they disabled it (which is most likely to happen when they are sure that they won't need it) I'll try to come up with something less use-cluttered later today.
Created attachment 185631 [details] new ebuild This is my proposal ( so far )
Created attachment 185679 [details] new(er) ebuild I'd say it's missing perforce use-flag. It also might be good to let user know that he needs to install perforce by hand if he enables it. Except for above, ebuild looks good. P.S. I also thought that debugger should be enabled by default, since it's one of main features in qtcreator.
As for designer plugin not building on my machine, if I create /.qmake.cache (yes, in slash aka root directory) then it builds like charm. I have the following thought on the matter: since gentoo does not have qt binary packages whatsoever, we might be better off to remove this check complitely, since it does not work as expected anyway (in some cases at least) I'm not sure if I should open another bug for that though.
First of all , I assume I can add an extra use flag ( enabled by default ) in order to build designer anyway. It is not a big deal. I agree it is good to have enabled by default the debugger use flag. About the perforce, well this is kinda tricky. There is no ebuild about this so either this plugin should be disabled or make an ebuild for perforce or as a final solution to add the ewarn you suggested. I ll try to do some tests locally and reply back
Ebuild and perforce client are now on qting-edge overlay. Will stay there for a couple of days for further testing before moving to the tree. Upstream has fixed the plugin_designer issue on git repository. So I included this fix on new ebuild until they release a new version
Created attachment 185791 [details] new ebuild Erm... It is sort of late to inform you about that, but it's not just designer, but also resourceeditor plugin which is not built. It can be forced by adding plugin_resourceeditor to subdirs. I mentioned it earlier, but maybe with too little emphasis. Also, there's no real reason to check if designer use-flag is enabled, since if it's not, corresponding line will be commented out on next step. And one more, if we add designer and/or resourceeditor lines to SUBDIRS, we should remove so-called autodetection so that there are no duplicates in SUBDIRS (if there are duplicates, it isn't likely to break anything, but it'll make unnecesary steps while compiling). To sum it up, I attach my proposal (based on r1 from qting-edge)
The key point here is to add the extra targets ( designer and resourceeditor ) on plugins.pro and then comment them if the use flag is not enabled. Resourceeditor is a major feature so it wont be a use flag for this. There will be one or two extra checks but this is not really important. Upstream seems that is aware of those buggies so it is ok to come up with a workaround for now Also make sure that you use the latest ebuild from qting-edge. I am pretty sure that I wont add perforce ebuild on portage due to licensing issues , so I shall add an ewarn message just like you proposed on your ebuild.
Created attachment 185893 [details] ebuild using add_missing_plugin patch I came up with a new ebuild . Missing plugins issue will be fixed using a patch instead of seds for a more clean solution
Created attachment 185894 [details, diff] add missing plugins patch The patch for the latest qt-creator-1.0.0-r1 ebuild
Make sure to remove # These two plugins require private headers from Qt and therefore don't work # with an installed/released version of Qt. exists($$(QTDIR)/.qmake.cache) { SUBDIRS += plugin_designer plugin_resourceeditor } else { message(Designer and Resource Editor plugins are not build! They require private headers and do not compile with your released/installed version of Qt) } with your patch then as well.
(In reply to comment #16) > Make sure to remove > > # These two plugins require private headers from Qt and therefore don't work > # with an installed/released version of Qt. > exists($$(QTDIR)/.qmake.cache) { > SUBDIRS += plugin_designer plugin_resourceeditor > } else { > message(Designer and Resource Editor plugins are not build! They require > private headers and do not compile with your released/installed version of Qt) > } > > with your patch then as well. > Done. Final ebuild ( and patch ) are now updated on the overlay. They will remain there for the next 48 hours and then will be moved on tree. Thanks you for your ideas and cooperation :)
On tree now. Thanks for your effort Closing now. Re open if needed +*qt-creator-1.0.0-r1 (24 Mar 2009) + + 24 Mar 2009; Markos Chandras <hwoarang@gentoo.org> + +files/add_missing_plugins.patch, -files/fix_headers_git.patch, + +qt-creator-1.0.0-r1.ebuild: + Introduce use flags for qt-creator plugins. Thanks to Livid + <g.livid@gmail.com> for his ebuilds,patches and effort. Dropping old + obsolete patch +
