As shown below, Threre are two directories that are exclusively included in the build depending on the build option. (by setting CMake)
ROOT
-- src
-- moduleA
-- codeA.c
-- moduleB
-- codeB.c
commonCode.c
funcSameNameDifferentImpl function exist in both codeA.c and codeB.c. It is used in commonCode.c
In this case, how I exclude codeA.c from CLion source control indexing? When I try to navigate or go to definition, IDE is NOT working as I expected. Even IDE bring me to source file excluded in build with kind warning 'This file does not belong to any project...'
I found out below guide and check overriding file type as plain text is working well. But, I think it is too ugly, not elegant.
https://www.jetbrains.com/help/clion/controlling-source-library-and-exclude-directories.html
Is there a nice way to exclude files and directories from CLion indexing?
I think it's intuitive behavior for indexing to change automatically depending on the build target.
Related
This may already have been asked and answered, but I couldn't find it if so.
I have VSCode and CMake setup and working fine and I am also using the ms-vscode.cmake-tools extension, and my c_cpp_properties.json has "configurationProvider": "ms-vscode.cmake-tools".
As part of my project CMakeLists.txt file I have:
configure_file(app_version.hpp.in app_version.hpp)
Obviously the actaul app_version.hpp file does not exist until cmake is run on the project and even then the actual file is placed into the build directory. The result of this is that the linter cannot find the file and so lots of red squiggles appear.
Is there a nice way to deal with this to make the linter happy, or do I have to specify a "fake" app_version.hpp with blank #defines etc?
You can tell CMake where to put the result of configure_file(), even back into your source tree. You'll still have to run cmake first. As an example...
configure_file(${CMAKE_SOURCE_DIR}/templates/app_version.hpp.in ${CMAKE_SOURCE_DIR}/include/app_version.hpp)
I can't think of a project that I work on that doesn't write back like this to the source directory, so running cmake at least once after checkout is second nature to me. Remember to set up your version control to ignore the output file, otherwise you get a different kind of "red squiggly line".
I'm trying to add a 3d model to the resources of an Appx in a cmake build. I have it successfully working with most formats, but files ending in .obj are being treated as compiled object files.
The cmake Visual Studio generator seems to always treat any file with an extension .obj as an object file and adds it to the vcxproj with the tag.
Is there a way to change the internal type of a file that cmake is using? Can I specify that this file is NOT an "EXTERNAL_OBJECT"?
Setting the VS_DEPLOYMENT_CONTENT to 1 doesn't help.
Adding it to the RESOURCES property doesn't help.
It looks like it might be an issue in the cmake source code itself where it checks if a file type if EXTERNAL_OBJECT before checking any other flags or types, and I can't figure out how to unset that type.
As per this issue on the cmake gitlab repo https://gitlab.kitware.com/cmake/cmake/issues/18820, there is a hacky fix solution but no "correct" fix yet.
Brad King:
As a very hacky not very futureproof workaround that abuses current implementation details, try:
get_property(loc SOURCE myfile.obj PROPERTY LOCATION)
set_property(SOURCE myfile.obj PROPERTY EXTERNAL_OBJECT 0)
The first line forces this code and therefore this code to run, causing CMake to initialize the EXTERNAL_OBJECT property earlier than it normally would. Once that is done then we can set the property back to 0.
A possible fix would be to teach the latter code (in CheckExtension) to not set the EXTERNAL_OBJECT property if it is already set. We can't change the default behavior of treating .obj files as objects to link, but we can at least make an explicit property setting work without the above hack.
I have confirmed that this works for the .obj files in our solution.
I'm writing a large OCaml project. I wrote a file foo.ml, which works perfectly. In a subdirectory of foo.ml's directory, there is a file bar.ml.
bar.ml references code in foo.ml, so its opening line is:
open Foo
This gives me an error at compile time:
Unbound module Foo.
What can I do to fix this without changing the location of foo.ml?
The easy path is to use one of OCaml build system like ocamlbuild or oasis. Another option would be jbuilder but jbuilder is quite opiniated about file organization and does not allow for the kind of subdirectory structure that you are asking for.
The more explicit path comes with a warning: OCaml build process is complicated with many moving parts that can be hard to deal with.
After this customary warning, when looking for modules, OCaml compiler first looks for module in the current compilation environment, then looks for compiled interface ".cmi" files in the directories specified by the "-I" option flags (plus the current directory and the standard library directory).
Thus in order to compile your bar.ml file, you will need to add the parent directory in the list of included directories with the -I .. option.
After all this, you will discover that during the linking phase, all object files (i.e. .cmo or .cmx) need to be listed in a topological order compatible with the dependency graph of your project.
Consequently, let me repeat my advice: use a proper build system.
I'm using Xcode (with C++) and my project layout (in the file system, not in Xcode) looks like this:
SubfolderA
-file_A_1, file_A_2
SubfolderB
-file_B_1, file_B_2
Right now I've set up this structure in Xcode via groups. And so, when I want to include file_A_2 in file_B_1, I write #include "file_A_2" in file_B_1.
Is there some way to make an inclusion look like #include "/SubfolderA/file_A_2", so that I can easily see to what directory/subfolder an included file belongs?
One way to see what's going on is to look at the Build Log and expand the line for compiling sourcefile.m. Look at the -I options being passed to the compiler.
If it's not to your liking you can add the source tree in the Build Settings > Header Search Paths to include $(ProjectDir)/srcroot and make it recursive, which saves you from adding each sub-folder individually.
In my experience this has never been necessary, however, as far as I can remember.
As far as the Xcode folders are concerned, if the top-level source folder is added then all sub-folders are automatically added when you add them to the filesystem, saving the hassle of keeping them in sync. You might need to add the top-level folder under the Source Files group for this to work, however.
Surprisingly, in Xcode's Build Settings I've added to User Header Search Paths non-recursive path to my project. This solved my problem.
I ended up here when I was having an issue with XCode while trying to include a header in a group by doing
#include "MyGroup/MyHeader.h"
Turns out the project structure and the file system weren't in sync, so I just had to remove my group from the project, put it in the correct place in Finder, then drag and drop it back into the project in the correct place and it worked for me.
I'm not sure if this is necessary or not, but I also have already set up my app's working directory because I am doing some game programming and need to be able to load in .png and make textures.
How can I get Eclipse to build many binaries at a time within one project (without writing a Makefile by hand)?
I have a CGI project that results in multiple .cgi programs to be run by the web server, plus several libraries used by them. The hand-made Makefile used to build it slowly becomes unmaintainable. We use Eclipse's "Internal Build" to build all other projects and we'd prefer to use it here too, but for the good of me, I can't find how to get Eclipse to build multiple small programs as result instead of linking everything into one binary.
Solution for this described there: http://tinyguides.blogspot.ru/2013/04/multiple-binaries-in-single-eclipse-cdt.html.
There is an excerpt:
Create a managed project (File > New C++ Project > Executable)
Add the source code containing multiple main() functions
Go to Project > Properties > C/C++ General > Path & Symbols > Manage Configurations
Make a build configuration for each executable and name it appropriately (you can clone existing configurations like Debug and Release).
From the project explorer, right click on each source file that contains a main() function > Resource Configurations > Exclude from Build and exclude all build configurations except the one that builds the executable with this main() function
All other code is included in all build configurations by default. You may need to change this depending on your application.
You can now build an executable for each main function by going to Project > Build Configurations > Set Active , Project > Build Project
Using Eclipse as your build system for production code seems like a bad idea in general. I think it's a great IDE and have used it extensively for both Java and C++ projects, but for a build system I firmly believe that Ant, make, and other dedicated build utilities are the way to go.
There are several reasons for this:
Dedicated build utilities offer the very flexibility you are looking for in generating multiple executable targets.
Ant and make support most conceivable arbitrary build process chains (though not quite all).
A dedicated build utility is likely to offer greater stability and backward-compatibility for build description file formats than an IDE tool like Eclipse. Also, I'm pretty sure that Eclipse's internal build feature is dependent on the ".project" file description, and the latter's format is probably not as stable as the build description format for either Ant or make.
General-purpose, basic build utilities are usually command-line-based, which makes it easy to integrate them with more sophisticated, higher-level build utilities for automated build management like Pulse, CruiseControl, etc.
The need that is motivating your question is telling you that it's time to make the switch to a better build tool.
There is a way to use buildconfigurations to create one binary (or shared library, in my case) from each build config. Using the answer above, this means to manually exclude all but the effective main file from each build config.
I just used the above answers to ease up working on my eclipse project that creates 14 shared libraries through 14 build configs. However, configuring the indivdual "exclude from build" setting was quite cumbersome, so I switched to using the following code relying on a preprocessor-directive as my complete main file:
/*
*main.cpp
*/
/* Within
* Project | Properties | C/C++-Build | Settings
* | GCC C++ Compiler | Preprocessor
* set the following defined Symbol:
* _FILENAME=${ConfigName}
*/
#define __QUOT2__(x) #x
#define __QUOT1__(x) __QUOT2__(x)
#include __QUOT1__(_FILENAME.cpp)
#undef __QUOT1__
#undef __QUOT2__
/* The above include directive will include the file ${CfgName}.cpp,
* wherein ${CfgName} is the name of the build configuration currently
* active in the project.
*
* When right clicking in
* Project Tree | (Project)
* and selecting
* Build Configuration | Build all
* this file will include the corresponding .cpp file named after the
* build config and thereby effectively take that file as a main file.
*
* Remember to exclude ALL ${CfgName}.cpp files from ALL build configurations.
*/
Note that it does nothing else then include another .cpp file which's name is deduced from the preprocessor and a symbol that is set in the compiler options. The symbol is ${CfgName} and will be replaced by the current config name by eclipse automatically.
One does not need to configure, which file is included in which build config. Just exclude all ${CfgName}.cpp files in every build and include main.cpp in every build.
PS: the answer from hovercraft gave me the idea to have a main file that does not contain code on its own. If one includes shared code from the different effective main files ${CfgName}.cpp, working on their code may become infeasible because header files in main.cpp will not be visible in them.
I did this until yesterday, but maintaining the code with broken index etc. was a big pain.
PPS: this procedure currently breaks the automatic rebuild of the main file if only the included .cpp file was changed. It seems that eclipse does not recognize the changes in ${CfgName}.cpp (which is excluded from build). So a manual rebuild is required after every change. This is currently bugging me ;)