I'm working on an embedded linux project. In this project, when i code, i usually go back and forth between a c++ user space application and a linux driver used by the user space application.
I use VSCode and in my C/C++ properties, to allow intellisense to be helpful when working on the linux driver, i needed add to the "includePath" the path to the linux include directory ("${workspaceFolder}/.../linux/include").
This is working fine from the linux driver point of view, the only problem is that this include path is used by intellisense also when i work on the user space application and obviously a few names and macros end up in conflict here and there (e.g. std::min and std::max conflict with the min and max macros from the linux include files).
So my question is: is it possible to specify an include path only for a subfolder of my project and not for the whole project? I would like intellisense to consider the linux/include folder as includePath but only for a specific subfolder of my project (the linux driver one). If it's possible, how can this be achieved?
I know i could consider the userspace application and the driver as two different and separate projects, each with its own cpp properties, but that would make switching between the two subprojects a bit more cumbersome.
Related
I have a C++ solution that uses several external libraries. For that to work, the compiler needs to be able to find all the header files. Currently this works by hard-coding the header locations into the various project files. But since the headers are installed in a different location on each computer, that means the project will only build on one machine.
What is the "correct" way to deal with this problem?
I feel like there should be a way to define which libraries each project needs, and then a separate file somewhere that says where those libraries are on this particular machine. But I don't know if MSBuild has anything remotely like that.
(Obviously, as well as the header files, we have exactly the same problem with the linker needing to find the object code to link in.)
It seems you can in fact fix this using environment variables. Either through the Visual Studio user interface itself, or just by editing the *.vcxproj file in a text editor, edit the include path from
D:\Libraries\Boost\32bit\include;D:\Libraries\GTest\32bit\include
to instead be something like
$(BOOST_ROOT)\include;$(GTEST_ROOT)\include
Now the project builds on any machine where the environment variable %BOOST_ROOT% is set to the right folder path. (And likewise for %GTEST_ROOT%.)
I am currently using Visual Studio 2013 (Update 4) for building Qt5.4.0 projects. I use the express version so I don't use the VS plugin. My .vcxproj files a generated from .pro files using build scripts and qmake.
When debugging my projects I sometimes try to step into Qt library code. To do this I added the path to the Qt source codes to the solution properties->Debug Source Files setting like described in a former post (VS2013 debugger can not find Qt sources).
Because I have many different projects and it would be a pain to update all of them in case of a Qt update I used a system environment variable "QTSRC" pointing to that path and added the following line to the solution:
$(QTSRC)
This worked like charm some time ago (with an older update of VS and a former Qt version 5.x).
But unfortunately it does not work anymore. It seems that VS now totally ignores the system environment variable (it also does not show any errors when I check the "check entries" button in the dialog).
Does anybody know what changed here lately and what must be done to fix this? It would be very annoying to add the path hardcoded to every project (which still works) and have to do this over and over again after Qt updates.
I'd look at the Property Pages which will allow you to set user defined values that you can share across different projects:
http://msdn.microsoft.com/en-us/library/675f1588.aspx
I use them to set global include paths, but it looks like you can set almost anything there. Set things in the .User pages if you want them used for all your projects but not included in the solution or project file itself.
A good, short, guide is here:
http://www.curlybrace.com/words/2012/12/17/setting-global-c-include-paths-in-visual-studio-2012-and-2011-and-2010/
I have finished with my "Study Timer" project which I had developed in c++ using SDL and an eclipse IDE but I am new to Eclipse and I would like to know about a way to get Eclipse to produce a new package out of my project which i can directly supply to the end user (similar to how a .swf file is created after publishing a Flash project) that does not contain the various files and folders required only for compilation!.
Specifically:
I have many files and folders in my project that are necessary for development but not for execution!
For example, my project contains: src/ , headers/ , images/ , fonts/ ,Debug/ (contains the actual exe file) , other dll files required to compile and run...
But for execution, I only need the Debug/ , images/ , and Fonts/ !
Is there a way by which Eclipse can automatically generate a clean finished project that can be supplied to the end user?
Is is possible to produce a new executable file that is not dependant on the images and fonts folder but rather have them embedded to produce a larger .exe file (similar to a .swf that contains all the dependant media)?
For a C++ project in order to deploy it to end-users, you just need the executable(s) applications plus any system-specific dependencies (you can inspect them with Dependency Walker and find the installer for the redistributables or package them along with your app). Notice that C++ executables are NOT portable across platforms, so if you compile an exe file for Windows, it will NOT run on Linux or Mac.
Then you might need an installer to deploy everything and install it (if install is needed at all) into another user's system:
A free and easy to use one: http://www.jrsoftware.org/isinfo.php
A professional and opensource not-so-easy-to-use one: http://nsis.sourceforge.net/Main_Page
A commercial professional one: http://www.installshield.com/
Not sure: if you're asking for "what should I give the users from my Eclipse C++ project?" then you should give them a Release version of your application. Release means "optimized and without debugging aid", it will almost surely be faster and smaller than your Debug-folder executable. Then package it as I described above.
In Eclipse you can switch to "Release" (assuming a standard C/C++ Eclipse IDE) from
Build Configurations->Set Active->Release
As already stated, a Release version doesn't contain debugging code (useless for an end-user and even potentially dangerous if you have code that you would like users not to know anything about), it is optimized (debugging code is easier to read even in assembly mode and easier to analyze for bug trackings) and thus the executable is often way smaller in size.
After question update: for your executable to use embedded resources (i.e. reference things inside its own binary executable rather than relying on outsie files) you need a resource file to include and link into your executable. This depends on the compiler as well (Eclipse is an IDE, something that helps you writing code but it's not the program that really creates your exe file.. something that lies under the hood of Eclipse and to which Eclipse "communicate" what to generate).
I am in the process of writing an application to communicate with Usb devices using WinUsb.dll. This is a user-mode library that allows communication with a device through winusb.sys installed as its driver in the kernel.
I am writing this application in C++ with Visual Studio 2008.
The header WinUsb.h is found in the Windows DDK so I add the include path "D:\WinDDK\7100.0.0\inc\ddk". I then get an error that Usb.h cannot be found which WinUsb.h includes, Usb.h is also in the ddk but in a different directory, so I add "D:\WinDDK\7100.0.0\inc\api" as an include dir.
Once I add that path then everything goes in the toilet and I start getting compile errors in stdio.h and a bunch of other weird places.
I really don't want to use the DDK build system and compiler in order to simply use this DLL, thats one of the main reasons I'm using WinUsb instead of writing a proper driver.
Has anyone built an application using WinUsb.dll and Visual Studio?
I am working on writing a cross-platform USB library and using the DDK build environment would make my build process much more complicated.
WinUsb is meant to be used by client applications for devices who load WinUsb.sys as their driver. However there doesn't seem to be a version of the WinUsb headers packaged for use in user-mode programs (not including UMDF drivers).
What I ended up doing was copying the few headers that support winusb.h out of the DDK and into a private directory, I then reference that directory as an include directory during the build.
These are the headers I needed to copy:
POPPACK.h
PSHPACK1.h
usb.h
usb100.h
usb200.h
winusb.h
winusbio.h
Once I had these included in a private directory and linked with winusb.lib in the DDK I was able to compile and run my project in Visual Studio.
I don't know if I'd recommend this method as it could be bad when the headers change between DDK releases, but I will open a CONNECT bug to see if I can get MS to create a package of WinUsb headers for use in client user-mode applications.
Historically the DDK and the SDK haven't played well together, but that problem was fixed sometime before Vista was released. However, it seems like you might be mixing parts of one SDK with another, which isn't good. I'd either use the DDK build environment or at least take a look at the INCLUDE path the DDK environment sets up and replicate it exactly in the VS project settings.
Note that you can use the DDK build environment and still use the VS IDE by creating a 'makefile project' or you might be able to use something like OSR's or Hollistech's DDKBUILD tools:
OSR's: http://www.osronline.com/article.cfm?article=43
Hollistech's: http://www.hollistech.com/Resources/ddkbuild/ddkbuild.htm
I haven't used these, so I'm not sure how well they work, but note that in spite of their similar names and uses they are different tools.
I have a few things that I cannot find a good way to perform in Visual Studio:
Pre-build step invokes a code generator that generates some source files which are later compiled. This can be solved to a limited extent by adding blank files to the project (which are later replaced with real generated files), but it does not work if I don't know names and/or the number of auto-generated source files. I can easily solve it in GNU make using $(wildcard generated/*.c). How can I do something similar with Visual Studio?
Can I prevent pre-build/post-build event running if the files do not need to be modified ("make" behaviour)? The current workaround is to write a wrapper script that will check timestamps for me, which works, but is a bit clunky.
What is a good way to locate external libraries and headers installed outside of VS? In *nix case, they would normally be installed in the system paths, or located with autoconf. I suppose I can specify paths with user-defined macros in project settings, but where is a good place to put these macros so they can be easily found and adjusted?
Just to be clear, I am aware that better Windows build systems exist (CMake, SCons), but they usually generate VS project files themselves, and I need to integrate this project into existing VS build system, so it is desirable that I have just plain VS project files, not generated ones.
If you need make behavior and are used to it, you can create visual studio makefile projects and include them in your project.
If you want less clunky, you can write visual studio macros and custom build events and tie them to specific build callbacks / hooks.
You can try something like workspacewhiz which will let you setup environment variables for your project, in a file format that can be checked in. Then users can alter them locally.
I've gone through this exact problem and I did get it working using Custom Build Rules.
But it was always a pain and worked poorly. I abandoned visual studio and went with a Makefile system using cygwin. Much better now.
cl.exe is the name of the VS compiler.
Update: I recently switched to using cmake, which comes with its own problems, and cmake can generate a visual studio solution. This seems to work well.
Specifically for #3, I use property pages to designate 3rd party library location settings (include paths, link paths, etc.). You can use User Macros from a parent or higher level property sheet to designate the starting point for the libraries themselves (if they are in a common root location), and then define individual sheets for each library using the base path macro. It's not automatic, but it is easy to maintain, and every developer can have a different root directory if necessary (it is in our environment).
One downside of this approach is that the include paths constructed this way are not included in the search paths for Visual Studio (unless you duplicate the definitions in the Projects and Directories settings for VS). I spoke to some MS people at PDC08 about getting this fixed for VS2010, and improving the interface in general, but no solid promises from them.
(1). I don't know a simple answer to this, but there are workarounds:
1a. If content of generated files does not clash (i.e. there is no common static identifiers etc.), you can add to the project a single file, such as AllGeneratedFiles.c, and modify your generator to append a #include "generated/file.c" to this file when it produces generated/file.c.
1b. Or you can create a separate makefile-based project for generated files and build them using nmake.
(2). Use a custom build rule instead of post-build event. You can add a custom build rule by right-clicking on the project name in the Solution Explorer and selecting Custom Build Rules.
(3). There is no standard way of doing this; it has to be defined on a per-project basis. One approach is to use environment variables to locate external dependencies. You can then use those environment variables in project properties. Add a readme.txt describing required tools and libraries and corresponding environment variables which the user has to set, and it should be easy enough for anyone to set up.
Depending on exactly what you are trying to do, you can sometimes have some luck with using a custom build step and setting your dependencies properly. It may be helpful to put all the generated code into its own project and then have your main project depend on it.