Related
I'm looking for a way to work on multiple projects in parallel in CLion IDE.
For now I can only work on each project in a window at a time, but I'm looking for a solution similar to Eclipse IDE (see below) - being able to see my different projects' directories on a side bar and choosing the one I want, compiling it by itself, etc.
Is there a way to do it?
Yes: CLion doesn't allow you to open multiple projects from the menu because it uses the CMake system, which is script based.
However, CMake is quite capable of encompassing multiple projects, and CLion will correctly parse your CMake file and show all relevant directories in the project explorer.
Example
To do this, just like in Visual Studio, you need a parent "solution" and one or more child "projects".
Here is a simple CMake example in which "my_solution" references two child projects, "my_application" and "my_library". Here, my three folders are arranged:
xxx/my_solution/CMakeLists.txt
xxx/my_application/CMakeLists.txt
xxx/my_library/CMakeLists.txt
And xxx/my_solution/CMakeLists.txt simply reads:
cmake_minimum_required(VERSION 3.7)
project(my_solution)
add_subdirectory("${PROJECT_SOURCE_DIR}/../my_library" "${PROJECT_SOURCE_DIR}/my_library_output")
add_subdirectory("${PROJECT_SOURCE_DIR}/../my_application" "${PROJECT_SOURCE_DIR}/my_application_output")
Note that it is also permitted to put my_application and my_library within the my_solution directory, as in Visual Studio.
No. CLion either:
opens a new window with the other project you want to work on
closes your current project and opens the new one in the current window
as you can see in the documentation. I think this is wanted in their design; probably to maintain CLion fast and reactive...
Adding some visual clues based on the answer from #c-z
This is how my project structure looking -
This is how my root level CMakeLists.txt is looking -
Finally, this is how my sub-directory level CMakeLists.txt is looking -
NOTE:
You may choose to remove the outer level main.cpp file (I've deleted it)
Also, you can remove the project level executable to remove it from the run configuration.
The title is fairly straightforward. If I hit the build button, it acts like the "Rebuild All" button. If I have two projects, lets call them PARENT and CHILD, and I make a change to Parent and click the "Build" button. The default behavior in VS is to rebuild PARENT AND CHILD, when it should only rebuild PARENT.
I was wondering if this is an option in Visual Studio and how I can change it.
Thanks.
There seems to be some inconsistencies in your question, so I'm going to define the terms I'm using, for clarity.
Build: Compile & link everything required for the application/project
Clean: Delete all files produced as part of a build.
Rebuild: Perform a clean, then a build.
My Visual Studio doesn't have a '(Re)build All' button, it does however have a '(Re)build Solution' button, so I'm going to assume you mean that. I'm also going to assume that where you've said rebuild PARENT and CHILD, you meant build PARENT and CHILD, and that it's not recompiling each and every file in the project.
The Build and Build Solution options are not the same.
Performing a Build will evaluate the current project (and its dependencies), compiling anything required.
Performing a Build Solution will evaluate all projects in the solution, compiling anything required.
So, if you have a solution with 3 projects:
Child
Service (Dependent on Child)
FrontEnd
Then, assuming the currently selected project is Service:
Build: Would evaluate/compile: Child & Service
Build Solution: Would evaluate/compile: Child, Service & FrontEnd
Now, I believe what you are seeing is that when you perform a build on Parent, VS is performing a build on Child as well, even though it hasn't changed. I would expect that it is evaluating Child, because it needs to know if it has changed. Without performing the evaluation, there's no way it can know, which is why in your output window you'll see that it has done something with the Child project. This is usually fairly quick, although it does add up if you have a lot of dependencies.
If you don't want VS to evaluate your dependencies when you build the parent, then there are approaches you can follow but you're choosing to step away from the tools protection so unless you're careful you may get binary mismatches etc...
Some options:
Unload child projects that you're not changing (right click in solution explorer and select unload). This hides the dependency so it doesn't get compiled).
Stop letting visual studio manage your dependencies. The safest way to do this is to remove the Project Based references and instead use Binary Based references (point at the compiled output from each dependency). But this can be a non-trivial undertaking, since you have to manage your project builds yourself.
I'd suggest you think twice about what it is you're asking and evaluate whether or not the time saving (there can be some) is worth the risk that now and again you might not build everything you needed to and so end up spending time chasing your tail.
Right click on the Solution from Solution Explorer, choose Properties.
From Configuration Properties > Configuration you could exclude particular project from the build process
From Common Properties > Project Dependansies you could create and remove project dependencies
Hope this helps...
Muse Extensions
I had a similar issue with about 40 projects in one solution. For me, the following setup felt a lot less hazardous than the other answers.
In Visual Studio, open up the Configuration Manager from the Build menu.
Select <New...> from the Active solution configuration drop down.
Enter a Name (e.g. Debug Interface) and either copy settings or create an empty configuration. You should be safe to deselect Also create new project configuration(s), especially if you only want to reduce the build time.
Select or deselect the projects you want to build with your new configuration and then close the Configuration Manager.
Enjoy the shorter build time using Ctrl + Shift + B or by just building the parent project. But don't forget to change to another build configuration if you want all projects to build again. Other projects that you've deselected can still be built if you right-click on them and select Build.
More information about the Configuration Manager can be found on MSDN: Configuration Manager Dialog Box.
Please review this article:
http://blogs.msdn.com/b/kirillosenkov/archive/2014/08/04/how-to-investigate-rebuilding-in-visual-studio-when-nothing-has-changed.aspx
[HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\12.0\General]
"U2DCheckVerbosity"=dword:00000001
When setting the registry key (I had to add it), just use the visual studio version that's applicable to you. E.g. 14.0 == VS2015
The diagnostic that's presented can help you determine why msbuild thinks things are out of date.
I also had this problem with C++. Dependent projects would completely recompile even when I did not change their source code or header files.
I turned off "Whole Program Optimization" for all of the dependent projects. Now my projects only rebuild if I change the source code. This option for C++ projects can be found in Properties->Configuration Properties->General.
Good Luck
I have just seen a situation like that in a solution with a couple of hundred projects. Whenever you clicked "build", VS would go and rebuild most of the projects, even if you just made a full build a second ago. Same problem if you only wanted to build a single project.
It turned out the problem was a circular dependency between projects.
Normally VS does not let you create a reference from one project to another if this would cause a loop.
This only concerns "Project references", however. VS does not prevent you from adding, say ../Debug/bin/OtherSubProject.dll as a DLL reference.
Now suppose we have a solution with 100 projects, most of them, say, dependent on CoreLibrary.dll. Suppose someone adds a reference from CoreLibrary.dll to ProjectX.dll (ignoring the fact that ProjectX already depends on CoreLibrary).
If we run the build now, then first CoreLibrary.dll is built, then ProjectX.dll and all other projects.
Now suppose we run the build again, without changing anything. VS sees that one of the dependencies of CoreLibrary.dll, namely ProjectX.dll is newer than CoreLibrary.dll, and hence CoreLibrary.dll needs to be rebuilt. But of course, rebuilding the core library forces the rebuilding of all other projects, including ProjectX.dll (which will again be newer than CoreLibrary.dll).
The way to resolve this problem is to get rid of all the circular dependencies which, in particular, means that you should not reference your other subprojects via DLL references. A temporary solution while you do it would be to go to Solution Properties -> Configuration and simply disable building for one of the projects in the loop (either CoreLibrary.dll or ProjectX.dll in the example above).
There is another common reason why VS may rebuild projects which were not changed: static files with "Copy to output directory: Always" set in their properties. Avoid those.
Finally, to debug all that and figure out what is causing the rebuilds, go to Tools->Options->Projects and Solutions->Build and Run, and enable "Diagnostic" output for MSBuild. Then search for the words "not up to date" in the output window while the solution builds.
Alt + B, U will build just your current project. Good shortcut if you don't want build all projects in solution.
For some reason when I open my project Compile button is disabled. I'm in C++ file and Ctrl+F7 doesn't work, Menu/Build/Compile is disabled and Compile in context menu in SolutionExplorer is disabled too. I can build project with F7, but I can't compile single file. It used to work just fine.
Any ideas why?
Had the same problem just because my project wasn't set as startup Project in my solution. Setting it solve the issue.
It seems that problem is on my side: someone in my team introduced some build scripts, which apparently work only for building whole project.
It might also be that a referenced property sheet could not be found. You can check this by attempting to view the properties of the project (Alt-Enter). A warning will be shown then when the property sheet cannot be found. Fix the property sheet reference, and probably you can compile again.
Note: question was asked/answered a while ago, but maybe it is useful for other persons.
My project was using an intermediate version of a unity build (sometimes called blob build) where groups of ~10 cpp files are put in the same compilation unit by being included in some blob_xxx.cpp. The project only considers the blob_xxx.cpp as source files, so technically the .cpp I was working on was not a source file for the project, so the Compile command was disabled (this is similar to what Paulius experienced).
In this case, you need to either select the blob_xxx.cpp file and Compile this single file, or switch to a non-blob build.
If your objective is to quickly test for compilation errors, you can comment out the includes for all the files you are not working on.
Alternatively, you may setup your project generation script to isolate the files you are working on in a separate blob (it's up to you to define what "working on" means; it may be a manual list or the list of cpp files that are checked out in Perforce if using it).
Each time I build my Visual C++ solution in Visual Studio 2010, the entire project (not the entire solution) recompiles.
There must be a flag or configuration somewhere to make VS compile only the changed files + depending files. Where is it?
UPDATES:
I set "Yes (/Gm)" to My project's configuration properties\C/C++\Code Generation\Enable Minimal Rebuild. It still compiles all the project's files upon F7.
If in addition you get the a message similar to:
Creating ".\Release\SomeLib.unsuccessfulbuild" because "AlwaysCreate" was specified.
when building, the reason might be that one of your projects refers to a header file which does not exist on disk (see here and here).
The first link also includes a small C# script to check for this situation. To fix, simply remove the reference to the non-existing header files from your project.
Update
It might be possible that you have your precompiled-headers setting on 'Create'. To fix, right-click your project in the solution browser and select: properties -> C/C++ -> Precompiled Headers -> Precompiled Header. Change the setting from Create to Use or Not Using Precompiled Headers.
VS should behave like you want it to by default; it sounds like something is flaky going on. Clean the project, and delete your settings files (e.g. .suo / vcproj..user / etc). There are several reasons for this, some of which I've seen are:
corrupt settings files
system date/time / time zone changes confusing vc
permissions issues on the source files
The post of tul was push forward for us, because we also have had some projects, which always did re-compile. As result I have found that:
yes, option 'Minimal Rebuild' somehow was corrupted in our visual 2010 projects. I guess, this could happens when they was transformed from visual 2005.
sign of "corruption" in a particular project is that this option is assigned, i.e. it is in bold. This could be only for some configurations, e.g. Release, or for some architectures, e.g. x64. It could be in bold "NO", but still recompiles.
FIX is as easy as the next steps:
select one or even few projects in solution
right click on project -> Properties
choose Configurations: "All Configurations"
choose Platform: "All Platforms" (if you have both x32/x64)
Expand C++ group
Goto "Code Generation"
note option "Enable Minimal Rebuild" -- most probably it will be empty, because different projects/configurations have different values
set this option to NO
click button Apply
again set this option to "inherited from parent"
click button Apply. NO you should see that this option becomes "NO" but in plain text.
DONE. No need even to recompile. The next build will be much faster.
So, I was having the same problem with one of our projects. First, I was able to debug the compiler output by selecting:
-> Tools -> Options -> Projects and Solutions -> Build and Run -> MSBuild project build output verbosity -> Detailed.
It turned out that someone had set the project to always create precompiled headers for all files (/Yc). I changed the option as listed below.
-> Configuration Properties -> Precompiled Header -> Use (/Yu)
Then I set the same option for stdafx.cpp to (/Yc). So compilation of the stdafx.cpp creates the precompiled header, and all the other .cpp files use the precompiled header. This is the default scenario, and I'm not sure how it had changed for out project.
Additionally, I have changed all our compiler settings to be consistent across all projects, including:
1) Setting: C/C++ -> Precompiled Headers -> Precompiled Header -> Use (/Yu)
Switch: /Yu
Reason: Faster build time.
2) Setting: C/C++ -> General -> Debug Information Format -> Program Database for Edit and Continue
Switch: /ZI
Reason: Enables edit-and-continue, thereby improving debugging capability.
3) Setting: C/C++ -> Code Generation -> Enable Minimal Rebuild -> Yes
Switch: /Gm
Reason: Allow and speed up incremental builds and this is required for /ZI.
Hope that helps. I spent a lot of time messing with our project build settings and reading posts to Stack Overflow, and in the end, I miss C#.
I had the same issue, except mine started without reason, without me making any project configuration changes.
I would edit one file, hit build, and it would rebuild the entire project.
After much painstaking experimentation, I found that turning OFF 'Minimal Rebuild' made the problem go away. With that off, I could once more change a file and it would only compile that one file.
The weird thing was, once I had successfully made a build with minimal rebuild disabled, I could turn it back on, and everything was back to normal.
Makes me think that some cache file somewhere had become corrupted perhaps? I had tried deleting all my intermediary directories without joy, so if it was a corrupt file I don't think it was anywhere within my project directories.
Hope this helps.
I'm working on a large, inherited C++ (really, mostly C) project developed and maintained under Visual Studio 2008. Technically, in Visual Studio terms, it is a "solution" consisting of eight "projects", and therein appears to be the rub.
As I'm sure most of you know, Visual Studio grays out the code that it believes to be #ifdef'd out. What I'm finding, though, is that it doesn't seem to do this correctly for the different projects. To keep matters simple, let's just call them Proj1, Proj2, ... Proj8. When I'm working on the Win32 Debug configuration of Proj5, I'd expect that the macros defined in the C/C++ Preprocessor properties configuration of Proj5 would determine what is grayed (or at least that there would be some straightforward way to make it so). Instead, I seem to be seeing views based on properties of Proj1. That is, if Proj1 defines some preprocessor macros that eliminate part of the code, I'm seeing that part grayed even when I'm working on Proj5. And the macros for Proj5 have no effect at all on what I see.
Yes, I did a complete clean and build (several, actually, and even saved everything off to SVN and started in a new top-level folder), and so I'm pretty sure this is not because of some vestigial files produced by an old build. And I'm pretty sure that in other respects Visual Sourcesafe "understands" the context correctly, because (1) the Build menu contains options related to Proj5, not Proj1; (b) at the bottom of the Project menu is "Proj5 properties..." not "Proj1 properties..."; and (c) there is no question that the #ifdef's are working in the program that is built: there are major feature differences, and they are as I'd expect them to be.
ADDED 27 Sept 2010 I still don't have an answer, so let me try this a different way: Assuming I've already run successful builds (which I have) is there anything other than the preprocessor properties and configuration of the currently selected project (and, as noted below, those of individual files, but that is moot in this case) that should influence what code is grayed?
Please see if these preprocessor directives might be set for the individual files. You can do this by right-clicking on a source file and selecting "Properties" from the context menu. It's somewhat counterintuitive to think that the directives can be set for individual files, not just for projects.
If that doesn't help, your best bet might be to use a text editor to look for the problem preprocessor definitions in each of the project files to try to get a better idea of what might be happening.
VS2010 is supposed to help with this. In VS2008, the no-compile browse cache is done after preprocessing, so it can accommodate only one set of macro definitions.
I don't believe that "Build Clean" or "Rebuild" will delete the .ncb files, since they are not part of the build process at all. I do know that deleting these files by hand fixes all kinds of weird behavior, but I'm afraid that in your case it's not going to be a lasting solution (the .ncb files will still get filled in based on a single configuration.)
Make the project the Startup Project and Remove and Re-add the offending Preprocessor Definition
Details:
I found a process that that fixes my MFC projects when this happens (at least temporarily). First I set the project I am working on as the startup project. Do that by right-clicking the project in the solution explorer and selecting Set as Startup Project. Then I go into the preprocessor definitions for the project and deleting the one that is not triggering and clicking OK. You will see a little progress bar a few seconds later appear in the lower right. Once it finishes, go back into preprocessor definitions for the project and add it back in again and click OK. After the little progress bar finishes again, you should see the correct code active again.