Tobias Hunger wrote: > Hi Anton, > > you raised some good points, all of which I agree with:-) > > On Thu, Mar 19, 2015 at 10:18 AM, Anton Makeev > <anton.mak...@jetbrains.com> wrote: >> * If it is useful to preprocess/compile/assemble individual files from >> IDEs, as made possible by the Makefiles and Ninja generators, we'll need >> to design that. >> http://thread.gmane.org/gmane.comp.programming.tools.cmake.devel/10711/focus=12429 >> >> >> This is definitely useful, but I’m not sure what kind of information >> needed here, >> as I see it, since we already know the files in the project, we can tell >> make/ninja to simply compile it. > > You asked me to use "cmake --build", so ideally that would be "cmake > --build . /full/file/path" and ideally it would work with all > generators without magic in the IDE:-)
It is also orthogonal to the metadata of the build itself and can be designed separately. I filed http://public.kitware.com/Bug/view.php?id=15465 if you want to engage in the design or implementation of that. > > Since I assume that not all build systems will allow to build > individual files, you might want to add a flag > "can_build_individual_files" or similar to the metadata that a > generator can use to flag the IDE on whether the generated build > system can build individual files or not. Then the IDE can hide that > option if it is not applicable. Yes. If it's not possible for xcodebuild/VS, then such a property can be added. Noted in http://public.kitware.com/Bug/view.php?id=15462 > I would also love to see subprojects:-) CMake allows for them, doesn't it? I don't know what 'subprojects' means to you. >> An additional though: here only the 'project information' aspect is >> discussed; though, to be fully machine-frienly, cmake should be able to >> also generate parseable output (error reports etc), provide the progress, >> etc. So, just to mull over, probably the discussed design should consider >> such future direction. > > Yes, that would be great, but I do not see how cmake can do that: It > delegates the actual build to external tools. Anton is talking about output of cmake itself afaik. > So in the end during a build we will always have to deal with whatever > output the generated buildsystem throws at us:-/ This again somewhat > limits the usefulness of allowing the user to pick whichever generator > they want: Some will just loose some or all the build issues. Only allow the user to choose a generator for whose make_program you have a parser for. Thanks, Steve. -- Powered by www.kitware.com Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Kitware offers various services to support the CMake community. For more information on each offering, please visit: CMake Support: http://cmake.org/cmake/help/support.html CMake Consulting: http://cmake.org/cmake/help/consulting.html CMake Training Courses: http://cmake.org/cmake/help/training.html Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/cmake-developers