Any "compile as library" option in QtCreator?
-
Is there any "build as library" option in QtCreator?
I mean: is there any way (a command, a plugin, etc.) to automagically compile a given file (more exactly: a pair of .h/.cpp files containing one or more class) into a shared library (.so, .dll, etc.), by adding all of the stuff listed here: "Creating Shared Libraries":http://developer.qt.nokia.com/doc/qt-4.8/sharedlibrary.html , while leaving out the main() code used to instantiate the class at dev time?
Thanks
-
When you create a new project, you can select shared library ( New project -> Other Project -> C++ library).
Changing TEMPLATE in your pro file to "lib" might also work.Regards,
Jake -
Do you do this regularly? Why?
I am trying to understand your use case to see whether this is something we should support. Currently we do not. It should be straight forward to set up a new project that compiles the sources as a library though.
-
No, I don't. This is the first time it happened to me (also because I'm quite new here) and I asked for a more confortable solution mainly out of curiosity.
I just created a custom dialog box (that is: a class derived from QDialog) as a experiment (call it a "spike") and now I would be happy to export it without having to clean up and modify the existing (and very messy) project or having to copy&paste the code in a new project.
Anyway, the solution proposed by jake007 is not what I hoped to see. Nor it would be a project template that compiles the sources as a library (even if I would greatly appreciate this feature, if implemented). This because both of these solutions imply the creation of a new project.
Instead, I hoped to find a way to export a "part" (a "component", a "custom widget", call it the way you like...) of a existing project as a shared (or even a static) library in order to be used in another project. More in detail, I hoped to find a way to export a single class or a file that contains one or more classes (a .h/.cpp file pair, actually...). Moreover, I would like to do this automagically (just by selecting "export this class/file/module/whatever as a library" from a menu).
This would make easier to create "components" beacuse you could be able to develop them in a evolutionary/agile way, inside a regular, full featured environment (a small, familiar Qt Creator project), making all of the experiments you need, exporting just the parts you need, just when you are ready to export them. It would also make easier to "promote" a humble, regular class (maybe developed by accident) to the "binary-level reusable component" rank of a library.
Of course, I'm aware that this would be a (quite hard) exercise in automatic code-refactoring/building-management. I just asked out of curiosity.
Thanks for you attention. Feel free to contact me if you need more info.
-
I would argue that you are doing a new project when you make (part of) your executable into a library: You are adding a new library project which can then be used by other projects.
Yes, that is not that simple with qmake, but conceptually I don't think changing an existing project is the right way to go: You usually want to keep your project in a working state, so kicking out stuff from it is not what I would want a IDE to do for me:-) Having a new, clean project created next to the existing one would be better I think: That way you can test the new project, revert it if it does not do what you need or just remove the old project instead.
Maybe it is just me, but I do get nervous when some piece of software removes stuff it thinks unimportant:-)
-
Yes, sure. I agree.
Nevertheless, it is not mandatory to change (or, even worse, destroy) the existing project.
A single class (or a file containing more than one class) could be easily copied into a new project (containing all of the required support code) and compiled as a library. I can easily do that by hand so I cannot see any reason why it cannot be done by (a reasonable complex piece of) software.
After all, when you "export" something from a project or a document, usually the original project/document remains untouched.
I could also imagine a GIT-based approach, based on branching. In this second case, the developer would get the added benefit of maintaining a explicit parent/child relationship between the original project and the exported component (and being able to merge back if required).