The property manager allows having different property sets for different configurations - for example, release and debug.
However, it still means you have to manually assign each property file to each configuration.
Is there some method to automatically assign a property set to a project based on some parameters (like configuration or platform)
a specific example:
I have a solution with many sub-projects.
this projects depend on various external libraries.
for each external library I have a .props file with the relevant directories and other parameters (include , lib, dll's...)
In some cases the directory names can be easily constructed using the default macros such as $(Configuration), $(Platform), etc.
However some libraries come with a less standard \ consistent naming convention.
for these cases I create .props file which are specific to a configuration (Debug\Release) - but it requires assigning the manfully to each project, which is tedious and error prone.
This is possible, at least in principle, see this post, for example. However, I did not find a practical way to use the whole power of MSBuild in combination with c++ projects from within the IDE. Whatever smart MSBuild expressions you write down in your property sheet, once you fire up the property manager dialog in the IDE everything gets overwritten with either defaults or the values inferred from there. This is an odd behaviour and completely different from other project types. Looks like they just wanted to keep the old pre-MSBuild style of editing VCProjects...
You can record a macro and use VBA to create/generate these with a button click.
Related
I'm working on a project that requires a whole multi-dimensional matrix of configurations. Theres (Debug / Release / Optimised / Final), (Editor / Non-Editor), (Win32 / Win64 / iOS / Android), (USA / Europe / Asia) etc. All with different build targets (ie win32_europe_debug_editor.exe) and their own set of libraries, includes, #defines and so on.
Is there a way to add more dropdowns to the project configuration toolbar in Visual Studio? At the moment there's "Platforms" and "Configurations". I've got win32/win64/ios/android in Platforms, but there's still dozens of different Configurations.
"Don't set your project up like this" is, unfortunately, out of my hands - this is the way the contracting company wants to do it, and we're bound to that.
I know that this is made a lot easier with just going through MSBuild, but I'm just hoping to find out if there's a way to do it while at least partially staying within the Visual Studio interface, just as that's what the rest of the team is used to. It's a tricky enough setup as it is, and I'd like to minimise the amount of extra cognitive load they have to take on!
Thanks!
You cannot add more parameters into .sln file, it is fixed to support only two -- Platform and Configuration. If you want Visual Studio to work with different parameters of your product, you have two options.
1.Expand your Configuration parameter to contain additional values, like a cross product of multiple sets. E.g. for your case, where your original parameters as follows:
Configuration={Debug, Release, Optimised, Final}
Editor={Editor, NonEditor}
Region={USA, Europe}
you might convert them to equivalent selection of configurations:
Configuration={Debug_Editor_USA, Debug_Editor_Europe, Debug_NonEditor_USA, Debug_NonEditor_Europe, Release_Editor_USA, ... }
This of course has scalability problems, so it only works with small set of additional parameters. Also, note that similar attempt to expand selection of Platform parameter would likely not work, because many targets work only with standard values of Platform property.
2.You can leave additional parameters in your .**proj files, with defaults that you can override from environment variables. E.g. if you have the following section in every project in your solution:
<PropertyGroup>
<EditorType Condition="'$(IDE_EDITOR_TYPE)' != ''">$(IDE_EDITOR_TYPE)</EditorType>
<EditorType Condition="'$(EditorType)' != ''">NonEditor</EditorType>
<RegionType Condition="'$(IDE_REGION_TYPE)' != ''">$(IDE_REGION_TYPE)</RegionType>
<RegionType Condition="'$(RegionType)' != ''">USA</RegionType>
</PropertyGroup>
,then values of additional parameters could be overriden by setting env variables, while default values will be NonEditor and USA. To have your VS IDE pick up non-default values, you have to do the following:
Open up VS cmd window
cd to location of your .sln
set IDE_EDITOR_TYPE=Editor
set IDE_REGION_TYPE=Europe
devenv MySolution.sln
VS IDE, launched this way will use these settings to perform build, debug, Intellisense, etc. BTW, when you change parameters, Intellisense needs to be rebuilt, the easiest way is to delete file MySolution.sdf before launching devenv.
I'm currently running into a problem that drives me a little bit mad. I hope it's a little stupid mistake on my side.
For convenience, I added an environmental variable in Windows 7, VS_BOOST_INCLUDE_HEADER with the value set to D:\01_Programs\boost_1_55_0\. My VC C++ include directories contain $(VS_BOOST_INCLUDE_HEADER).
Remark: I changed that variable this morning, but I've rebooted my computer since than multiple times.
Now my VS project complains it can't find any of the boost includes anymore, e.g. <boost/asio.hpp>. If I add the whole path manually to the include paths (adding D:\01_Programs\boost_1_55_0\ as text to my VC C++ include directories), everything works as expected.
To avoid a simple typo, I added a post-build event:
echo $(VS_BOOST_INCLUDE_HEADER)
That works as expected:
1>PostBuildEvent:
1> D:\01_Programs\boost_1_55_0\
All my other environmental variables still work as expected, even those that were renamed this morning as well.
Any ideas?
What am I doing wrong?
Maybe I'm late to the party, but a possible scenario is when you
run VS as administrator
adjusted a User environment variable
Then it would make some sense for VS to see the System environment only and still use the old value.
If you decide to use property sheets the msdn has clear docs
"If you have a common, frequently used set of properties that you want
to apply to multiple projects, you can use Property Manager to capture
them in a reusable property sheet file"
Under the view menu, chose property manager and add a new sheet.
You can then make your project inherit its settings from this property sheet, thereby just setting this in one place.
In Visual Studio 2012 C++ project property Page, macro dialog
We can find different macro expanding syntax,
$(TargetPath)
%(OutputFile)
#(_TargetFramework20DirectoryItem)
What's the different?
BTW, Can we define our own new macro easily in Visual Studio 2012? Beside create a new project property sheet.
I just want to a simple new macro, if so, all my depends can be calculated base on this macro.
For example:
$(DependsBaseDir) = $(ProjectDir)..\..\..\
$(IncludePath) = $(DependsBaseDir)include;$(DependsBaseDir)abc\inc;$(DependsBaseDir)xyz\pub_inc
$(LibraryPath) = $(DependsBaseDir)lib
Using project property, I cannot archive my purpose. Since $(DependsBaseDir) depends on $(ProjectDir). I have to use environment variable, which is a VERY VERY BAD decision and it is hard to move project among machines. Or I have to repeat $(DependsBaseDir) value everywhere. If $(DependsBaseDir) changed, it do change, fix depends is a disaster. I have to calculate right dots, then replace it everywhere...This simple example is hard enough. Do not say $(SolutionDir), project shared in different solutions.
$ expands a property, % expands an item definition. Look at text of a vcxproj and you can see the difference.
You can define your own properties in the project file, and the suggested place is under "UserMacros". Yuo can define your thing like
$(ProjectDir)......\
there, and use it with $(DependsBaseDir) later on. AAMOF you can even use expressions applicable to C# string.
If you don't want to edit the project itself, you can put that in a separate .props file and import that manually or using the property manager.
For my application (an MMC snap-in) I need to create a single native DLL containing strings that are localized into different languages. In other words, if you were to inspect this DLL with Visual Studio, you would see multiple string tables, each associated with a different locale but containing the same string IDs.
The approach I would like to take is to have various subdirectories under my project directory such as "de", "en", "es", etc (i.e. one for each language). Inside each subdirectory would be a file called "Resources.rc" which would be the RC file containing the strings for that language. Having my resources in this structure would be ideal for the localisation team.
I have managed to create my various RC files and have added them to my Visual C++ project. They all appear correctly in Solution Explorer in Visual Studio (you basically see five instances of an entry called "Resource.rc", but each entry points to a different file).
The problem comes with building my project. It seems that only a single one of the RC files (the one that is specified first in the vcproj file) is compiled into a RES file and included into my DLL. Presumably this is because Visual Studio does not like the fact that the RC files all have the same name.
Is there any way to achieve what I want?
Thanks!
Yes. And No.
If you want multiple RC files you are going to have to leverage off the Operating systems support to have multiple resources in one file. In the resource editor, for each resource, you can set its locale AND the resource editor will allow you to have multiple resources with the same ID, as long as their locale is different.
So, your first step would be to edit each of the RC files to ensure that the resources in one are English/US, another contains French etc.
Next, get the main RC file to #include the others.
Lastly, and this is the problem, you need to rely on the Operating systems logic to load the correct resources. If you are happy to let the locale of the PC determine what UI language is used you have done enough.
If you want to provide a menu option allowing users to change languages: SetThreadLocale used to be an easy way to switch the Locale of loaded resources on the current thread. Since Windows 2000 some unfortunate overloaded usage of the API has caused MS to deprecate its usage in favor of requiring App Developers to always use FindResourceEx - which really doesn't help you if you want, for example, to load a string from a string table.
If you really want an easy way to have a user selectable UI language, then you need to place each of your .rc files into a seperate dll. and then LoadLibrary on the appropriate language resource dll.
I was going to create the C++ IDE Vim extendable plugin. It is not a problem to make one which will satisfy my own needs.
This plugin was going to work with workspaces, projects and its dependencies.
This is for unix like system with gcc as c++ compiler.
So my question is what is the most important things you'd need from an IDE? Please take in account that this is Vim, where almost all, almost, is possible.
Several questions:
How often do you manage different workspaces with projects inside them and their relationships between them? What is the most annoying things in this process.
Is is necessary to recreate "project" from the Makefile?
Thanks.
Reason to create this plugin:
With a bunch of plugins and self written ones we can simulate most of things. It is ok when we work on a one big "infinitive" project.
Good when we already have a makefile or jam file. Bad when we have to create our owns, mostly by copy and paste existing.
All ctags and cscope related things have to know about list of a real project files. And we create such ones. This <project#get_list_of_files()> and many similar could be a good project api function to cooperate with an existing and the future plugins.
Cooperation with an existing makefiles can help to find out the list of the real project files and the executable name.
With plugin system inside the plugin there can be different project templates.
Above are some reasons why I will start the job. I'd like to hear your one.
There are multiple problems. Most of them are already solved by independent and generic plugins.
Regarding the definition of what is a project.
Given a set of files in a same directory, each file can be the unique file of a project -- I always have a tests/ directory where I host pet projects, or where I test the behaviour of the compiler. On the opposite, the files from a set of directories can be part of a same and very big project.
In the end, what really defines a project is a (leaf) "makefile" -- And why restrict ourselves to makefiles, what about scons, autotools, ant, (b)jam, aap? And BTW, Sun-Makefiles or GNU-Makefiles ?
Moreover, I don't see any point in having vim know the exact files in the current project. And even so, the well known project.vim plugin already does the job. Personally I use a local_vimrc plugin (I'm maintaining one, and I've seen two others on SF). With this plugin, I just have to drop a _vimrc_local.vim file in a directory, and what is defined in it (:mappings, :functions, variables, :commands, :settings, ...) will apply to each file under the directory -- I work on a big project having a dozen of subcomponents, each component live in its own directory, has its own makefile (not even named Makefile, nor with a name of the directory)
Regarding C++ code understanding
Every time we want to do something complex (refactorings like rename-function, rename-variable, generate-switch-from-current-variable-which-is-an-enum, ...), we need vim to have an understanding of C++. Most of the existing plugins rely on ctags. Unfortunately, ctags comprehension of C++ is quite limited -- I have already written a few advanced things, but I'm often stopped by the poor information provided by ctags. cscope is no better. Eventually, I think we will have to integrate an advanced tool like elsa/pork/ionk/deshydrata/....
NB: That's where, now, I concentrate most of my efforts.
Regarding Doxygen
I don't known how difficult it is to jump to the doxygen definition associated to a current token. The first difficulty is to understand what the cursor is on (I guess omnicppcomplete has already done a lot of work in this direction). The second difficulty will be to understand how doxygen generate the page name for each symbol from the code.
Opening vim at the right line of code from a doxygen page should be simple with a greasemonkey plugin.
Regarding the debugger
There is the pyclewn project for those that run vim under linux, and with gdb as debugger. Unfortunately, it does not support other debuggers like dbx.
Responses to other requirements:
When I run or debug my compiled program, I'd like the option of having a dialog pop up which asks me for the command line parameters. It should remember the last 20 or so parameters I used for the project. I do not want to have to edit the project properties for this.
My BuildToolsWrapper plugin has a g:BTW_run_parameters option (easily overridden with project/local_vimrc solutions). Adding a mapping to ask the arguments to use is really simple. (see :h inputdialog())
work with source control system
There already exist several plugins addressing this issue. This has nothing to do with C++, and it must not be addressed by a C++ suite.
debugger
source code navigation tools (now I am using http://www.vim.org/scripts/script.php?script_id=1638 plugin and ctags)
compile lib/project/one source file from ide
navigation by files in project
work with source control system
easy acces to file changes history
rename file/variable/method functions
easy access to c++ help
easy change project settings (Makefiles, jam, etc)
fast autocomplette for paths/variables/methods/parameters
smart identation for new scopes (also it will be good thing if developer will have posibility to setup identation rules)
highlighting incorrect by code convenstion identation (tabs instead spaces, spaces after ";", spaces near "(" or ")", etc)
reformating selected block by convenstion
Things I'd like in an IDE that the ones I use don't provide:
When I run or debug my compiled program, I'd like the option of having a dialog pop up which asks me for the command line parameters. It should remember the last 20 or so parameters I used for the project. I do not want to have to edit the project properties for this.
A "Tools" menu that is configurable on a per-project basis
Ability to rejig the keyboard mappings for every possible command.
Ability to produce lists of project configurations in text form
Intelligent floating (not docked) windows for debugger etc. that pop up only when I need them, stay on top and then disappear when no longer needed.
Built-in code metrics analysis so I get a list of the most complex functions in the project and can click on them to jump to the code
Built-in support for Doxygen or similar so I can click in a Doxygen document and go directly to code. Sjould also reverse navigate from code to Doxygen.
No doubt someone will now say Eclipse can do this or that, but it's too slow and bloated for me.
Adding to Neil's answer:
integration with gdb as in emacs. I know of clewn, but I don't like that I have to restart vim to restart the debugger. With clewn, vim is integrated into the debugger, but not the other way around.
Not sure if you are developing on Windows, but if you are I suggest you check out Viemu. It is a pretty good VIM extension for Visual Studio. I really like Visual Studio as an IDE (although I still think VC6 is hard to beat), so a Vim extension for VS was perfect for me. Features that I would prefer worked better in a Vim IDE are:
The Macro Recording is a bit error prone, especially with indentation. I find I can easily and often record macros in Vim while I am editing code (eg. taking an enum defn from a header and cranking out a corresponding switch statement), but found that Viemu is a bit flakey in that deptartment.
The VIM code completion picks up words in the current buffer where Viemu hooks into the VS code completion stuff. This means if I have just created a method name and I want to ctrl ] to auto complete, Vim will pick it up, but Viemu won't.
For me, it's just down to the necessities
nice integration with ctags, so you can do jump to definition
intelligent completion, that also give you the function prototype
easy way to switch between code and headers
interactive debugging with breaakpoints, but maybe
maybe folding
extra bonus points for refactoring tools like rename or extract method
I'd say stay away from defining projects - just treat the entire file branch as part of the "project" and let users have a settings file to override that default
99% of the difference in speed I see between IDE and vim users is code lookup and navigation. You need to be able to grep your source tree for a phrase (or intelligently look for the right symbol using ctags), show all the hits, and switch to that file in like two or three keystrokes.
All the other crap like repository navigation or interactive debugging is nice, but there are other ways to solve those problems. I'd say drop the interactive debugging even. Just focus on what makes IDEs good editors - have a "big picture" view of your project, instead of single file.
In fact, are there any plugins for vim that already achieve this?