I’ve been looking at the Introjucer exports lately, and I’ve been wondering if it’s not better and less hassle to,
instead of generating project files seperately for each and every IDE and version and OS,
just generate cmake or msbuild projects and provide simple batch files that use these tools’ capabilities to do the
actual project file generation.
That would certainly save Jules from having to keep on adding more and more options for export, as well as provide
a clean and proven working way of auto-generating solutions etc for different IDE versions, with new target versions coming along
with only the need to provide a batch file with the right switches instead of a whole new file format (arrangement).
The difficult bit is not generating the project files - that’s easy, they’re mainly just xml or text, and it took very little time to implement them all.
To generate those files via a 3rd party layer like cmake would probably be harder, not easier, because it’d involve both knowing what the final files must contain, and also knowing how to persuade cmake to create that result.
Well, not so much. First, by using cmake or msbuild (on windows), there is only ONE (or two) export target(s) left, which is easier to maintain for sure.
Second, at least for msbuild, it’s plain XML, too, and actually not very different from Visual Studio’s own project format.
The benefit is simply that it’s able to be built without the IDE, but from command line, and it can auto-generate the appropriate visual studio exports on it’s own, including x86 and x64 architecture builds etc.
When I first decided to build the introjucer, my first approach was also to use cmake, but on investigating, it really was far simpler to just cut out the middle-man.
But would you accept a contribution for a CMAKE target in the introjucer?
I wrote some really ugly cmake files to get our juce plugins build with cmake, so I second your opinion that it is a PITA to get cmake to make all those important tweaks, for example to build RTAS plugins in windows or set some “magic” xcode properties. And as long as your target platforms are just Visual Studio and XCode, it’s a pleasure to just use the Introjucer instead of having to mess with cmakie.
But currently I am working on my master thesis in a university environment that is a lot more heterogeneous, most people are using linux with either qtcreator or eclipse, and even those on windows don’t have visual studio installed.
I ended up hand-writing a simple cmake file for my project that could be easily generated with the IntroJucer. So at least for simple command line or gui applications, adding CMake as a target shouldn’t be that difficult. I am not so optimistic regarding plugins, our CMakeLists.txt turned out to be quite complicated and contain company-internal dependencies - but if there are others with more CMake knowledge here, I’d be happy to share our knowledge and work on a nicer solution.
yes… perhaps. Although I have a suspicion that it could be a pain to maintain, because surely a cmake target would need as many settings as all the other exporters combined?
Perhaps it’s possible to do a cmake exporter that simply provides a text box for your custom settings, and which only generates the very basic stuff automatically? (But I really don’t know anything much about how it works)
Sounds like a good idea - the common stuff like preprocessor definitions, header paths, linker paths & libraries have corresponding cmake commands that should be easy to generate and that work without surprises for different IDEs. I second that it would be difficult and hard to maintain more options for all the other cmake magic you can do. But two text areas where you can enter custom cmake code that is put before&after the generated stuff should allow anyone to use advanced cmake features. I’ll check our hand-maintained cmake files later for anything that doesn’t fit into that model.
