Is there anyway to keep CLion's project files (i.e. .idea directory) in a separate directory than the project? This feature already exists in IntelliJ IDE but I can't find something similar to CLion...
I'm looking for a structure like this one:
~/my_project/CMakelists.txt
~/my_project/other_source_files
~/project_files/my_project/.idea
Related
Suppose we have a project A with output directory bin/ and a project B with output directory test/bin/. Project A needs to have a certain configuration file copied to its output directory. Currently, this is being done by adding a pre-build event that looks like
COPY /Y "$(ProjectDir)..\config.ini" "$(TargetDir)"
Project B has A as dependency. When project B builds, the binary resulting from A is correctly copied to the output directory of B, but the config file isn't!
How can we achieve that all files that A needs to have are also copied to the output directory of B?
What you want is a Link File. I've used these before to ensure that connection.config files are copied to multiple projects.
I created a sample solution that mimics your described scenario as seen below. The ConsoleApplication1 references the ClassLibrary1 project. In the solution, I created a solution folder config and added the shared config that needs to be copied.
In order to have a single file that is copied across multiple projects, you must create a single file, and then add it as a link to the projects that need it. This can be done by right clicking on the project, and choosing Add -> Existing Item.... You will see a dialog as show below and you want to choose the Add as Link option from the dropdown instead of just Add.
Finally, edit the properties for the linked file to copy it to the output directory.
I have a number of projects which are joined into a solution. Every project has it's own directory structure, and csproj files are located on diferrent level of folder structure.
Every csproj has OutputPath property specified. OutputPath - is a relative path and it varies from project to project in such a way so all projects have the same output dir.
It is work OK if I build a separate project. But everything changes if I try to build solution file. In this case every project output folder differs (depends on a number of '..\' in that project's OutputPath).
I do know, that before some moment all was working fine. Nobody changed build.cmd neither any sln or csproj files. But now I have situation described above.
So my question is - what affects how relative path is evaluated? I mean how can I force relative OutputPath to be evaluated starting from folder where csproj file of that particular project is located. Not from folder where .sln file is.
Let's assume I have following directory structure:
dir1
a.sln
dir2
a.csproj
dir21
dir3
b.csproj
a.csproj has output path set to '../../_bin' which is just above dir1 if counted from a.csproj folder
b.csproj has output path set to '../../../_bin' which is same - just about dir1 if counted from b.csproj
a.sln contains both - a.csproj and b.csproj.
When I run msbuild I get a project build to 'dir1/../../_bin' and b project to 'dir1/../../../_bin' - both relative paths of projects files are counted from solution file location, not project files.
Well, I was able to find out what was causing this. That was custom .targets file, which was inferring SolutionDir property at the start of any msbuild.
I did find out that by using MSBuild Explorer. The tool proved to be very useful in my case - I was not aware of third party .target files on my system.
From Msbuild Import Element description
Relative paths in imported projects are interpreted relative to the
directory of the importing project. Therefore, if a project file is
imported into several project files in different locations, the
relative paths in the imported project file will be interpreted
differently for each imported project.
All MSBuild reserved properties that relate to the project file, for example, MSBuildProjectDirectory
and MSBuildProjectFile, that are referenced in an imported project are
assigned values based on the importing project file.
If you add more details or few samples to your question - it will be easier to understand exact problem.
Edit:
Okay, lets try to pinpoint that mystery. First of all - OutputPath could be affected by Environment variables.
2nd - during build sln file transformed into msbuild project file format and stored in temp file. You can get that temporary file if you execute in cmd "set msbuildemitsolution=1" and then trigger build via command line. There you can check that file and see how your individual projects called. But I suppose you will see multiple .csproj /> entries. And global msbuild properties inherited by that calls.
So I suspect if everything was fine before some point and no changes were made - you are missing OutputPath environment variable or some other variable that contributed to construction of OutputPath.
BTW - I think if you want to fix your issue with forcing relative dir - you also can use $(MSBuildProjectDirectory). This is one of msbuild reserved properties (from here), but this will require yo adjust your OutputPath in each csproj file. What i, personally, prefer to avoid, because it could affect some other targets and introduce subtle issues.
I am doing some housecleaning with our VC++ project structure and I had the following weird directory setup. In one folder, called "USBAScan", I have a Visual C++ project file, named "USBAScan.vcxproj". USBAScan has a subfolder that is also called "USBAScan". It also has a VC++ project file named "USBAScan.vcxproj".
My VC++ solution references a project named "USBAScan.vcxproj". Its project file property is "USBAScan\USBAScan\USBAScan.vcxproj". I remove this project and delete the project file USBAScan\USBAScan\USBAScan.vcxproj. In the solution I try to add USBAScan\USBAScan.vcxproj. I get the following error message:
"The project file USBAScan\USBAScan\USBAScan.vcxproj has been moved, renamed or is not on your computer".
Although I'm trying to add USBAScan\USBAScan.vcxproj, the solution is trying to add USBAScan\USBAScan\USBAScan.vcxproj. Why would it behave this way?
I as using visual studio 2010. My solution is having more than one projects in it which are have relationships to each. When I adding a reference to a other project I can use public components (classes,enums ) of that. But when I compile it it gives error saying that those classes are not referenced(Not available).
But when I change the folder structure(When I reduce the level of folder hierarchy/when project folders borings to the root folder ex: d:\ ) it works fine.
Is it because of the length of the folder hierarchi ?
Check your namespaces
When you're adding reference, add it using Project References. So what it does is it compiles the dependencies first. Check if all projects are compiling individually.
Verify target framework versions
No, it is not because of folder hierarchy.... it is because not setting hierarchy properly !!
Follow this steps:
Lets say you have project A and project B.
Project A is dependent on Project B. So we need to add dependency of Project B to Project A.
So right click on Project A -> Open Folder in File Explorer.
Then check which folder it opens into (Lets call it "source folder") and check where the project files whose dependency to be added (Lets call it "destination folder") are located from that folder location. Add the relative path from source to destination folder. (Ex: "..\..\destination folder" ).
Add this relative path in Project A Properties -> Configuration Properties -> C/C++ ->Additional Include Directories.
Good luck.
Yes, hangar18 has suggested correctly. Add reference of each project (Static Libraries) to you execuatble project ( Console Application Project / Startup project).
Also add path of each folder where the header files and corresponding C/C++ files are residing.
I have a project that is stored in a Subversion repository.
In this repository, in a different folder, I have a set of libraries that I use in many of my projects. These libraries are stored as binary files, ie. the dll's, pdb's, and xml's.
Here's an example layout:
<repo-url>
\Libraries
\SQLite
\SystemHooks
\Moq
In the application project, I add a "libs" directory, then add a svn:externals reference property to that directory to pull in the libraries I need.
For instance, for this project I am working on now, which prompted this question, I need the SystemHooks library, so in my app project folder structure, it now looks like this:
SketchingMode <-- solution folder, other projects here as well
SketchingMode <-- app project folder
libs
SystemHooks
The nice thing about this is that I can more easily update the libraries, and just use the -rXYZ specifier for the externals definition to avoid pulling in newer versions than I'm ready to accept, and still have only one copy of each file/version in my repository.
The bad thing, in this particular case, is that one of the dll's in the SystemHooks directory (2 if I want the pdb as well) needs to be copied to the output directory, not referenced by the project.
References work as normal, but once I tag one of the files in this directory as "Content" and "Copy always" or "Copy if newer", then the libs and SystemHooks directory structure is also copied to the output directory.
As such, after a build, my on-disk directory structure looks like this:
SketchingMode <-- solution folder, other projects here as well
SketchingMode <-- app project folder
libs
SystemHooks
bin
Debug <-- main build output here
libs
SystemHooks <-- 1-2 files in here
Is the only way to avoid this to use the post-build steps and just add the necessary copy statements? Or can I somehow tweak the project file to avoid copying the full structure like that?
Just to make it clear, in the bin\Debug directory, I don't want another layer of libs\SystemHooks in there, and all the files presently being copied to the bin\Debug\libs\SystemHooks folder needs to be copied to the bin\Debug folder instead.
How about checking out the libs directory to the level of the solution rather than the project? That is what we do since library assemblies tend to be used by multiple projects; placing direct inside one project's directory would not make for a highly shareable resource.
SketchingMode solution
SketchingMode proj
bin
Debug
Release
Libs
SystemHooks