I have a legacy code base which has CMake configuration and .sh files which calls build commands with respect to build type ( release, relwithdebinfo etc.) as well as does a lot of things.
I have to work over codebase. So far I used STM32CubeIDe. I imported the project as existing Makefile project and then I changed C/C++ Build directory to where makefile outputs converted.
So whenever I did a change on the code, I hit the build command over UI and it calls make command at where I modifed the path above.
This is working but In case of a need of debug then I had to use .elf outputs and OZONE J link Debug program.
I have to do build+debug in same environment but eclipse is slow and making me struggle.
How can I make VSCode host to my legacy code in order to build and debug and also navigate in code i.e go to the definition of code in VSCode, not only building.
Please navigate me if anything needs to share from existing code base, if there is still unclear.
How can I generate the code for both x86 and x64 using MIDL?
I've created an IDL file in Visual Studio 2010, and when I compile the product as in x86 mode and afterwards in x64 I've got to "touch" the IDL file so it will regenerate the code relevant for x64. Can I somehow tell MIDL to generate both codes into the same file?
An IDL file defines an interface, that interface could use 64-bit platform features or 32-bit platform features. An IDL can be used to generate a stub; if an interface doesn't have 32-bit-platform-specific definitions or 64-bit-platform-specific definitions, supposedly on stub can be generated (i.e. one IDL file). But, that depends on the interfaces that you're exposing. Short answer: if you define you interfaces to be 32-bit and 64-bit compatible you shouldn't need two different IDL files--otherwise you need two different IDL files.
Without knowing what "touch" (which generally means updating the date/time of a file, w.r.t. software engineering) means, it's hard to say specifically what you need to do.
If you're referring to the files under the Generated Files folder, you won't see them change if all you change is the target platform (well, unless you've placed #ifdef blocks in the IDL that use platform-specific defines). Remember, the output of MIDL is source code, not binaries. The names of the datatypes used in the generated code won't change, so the output from MIDL will be the same even though the machine architecture the compiler is targeting is different.
You can verify this by making copies of the XXX_i.h and XXX_i.c files and comparing them between platforms. To do this, Build, make copies, Rebuild, then compare the files; the only thing that should be different is the timestamp.
So, to get back to your original question: you're already doing it!
I know this is an old question, but should anyone else hit this here is how I solved it.
In the project containing the IDL file, I added a pre-build event to all platforms and configurations that deleted the MIDL output files like this...
if exist $(ProjectName).h del $(ProjectName).h
if exist $(ProjectName)_i.c del $(ProjectName)_i.c
if exist $(ProjectName)_p.c del $(ProjectName)_p.c
I could have gotten away with just deleting the proxy (_p) file as that's the only platform specific MIDL generated file.
If your proxy stub source files have different names or extensions, use those.
I'm having the Program "make" not found in PATH error in eclipse. I checked the path variable which is:
C:\cygwin\bin;
%JAVA_HOME%\bin;
%ANT_HOME%\bin;
%ANDROID_SDK%\tools;
%ANDROID_SDK%\platform-tools;
%ANDROID_NDK%;
%CommonProgramFiles%\Microsoft Shared\Windows Live;
C:\Program Files\NVIDIA Corporation\PhysX\Common;
%SystemRoot%\system32;
%SystemRoot%;
%SystemRoot%\System32\Wbem;
%SYSTEMROOT%\System32\WindowsPowerShell\v1.0\;
C:\Program Files\Microsoft SQL Server\100\Tools\Binn\;
C:\Program Files\Microsoft SQL Server\100\DTS\Binn\;
C:\Program Files\Git\cmd
The PATH starts with the folder which contains make (I checked and make.exe is in there), but eclipse still goes Program "make" not found in PATH.
I have tried changing the path and restarting several times but nothing seems to change.
You may try altering toolchain in case if for some reason you can't use gcc. Open Properties for your project (by right clicking on your project name in the Project Explorer), then C/C++ Build > Tool Chain Editor. You can change the current builder there from GNU Make Builder to CDT Internal Builder or whatever compatible you have.
Are you trying to run "Hello world" for the first time? Please make sure you choose proper toolchain. For Windows you have to choose MinGW GCC.
To make MinGW GCC compiler as default or change you original project with error "Program “make” not found in PATH" or "launch failed binary not found eclipse c++" when you trying to run program simply go to
Windows >> Preferences >> C\C++ Build >> Tool Chain Editor >> Change Current toolchain to MinGW GCC
In MinGW, I had to install the following things:
Basic Setup -> mingw32-base
Basic Setup -> mingw32-gcc-g++
Basic Setup -> msys-base
And in Eclipse, go to
Windows -> Preferences -> C/C++ -> Build -> Environment
And set the following environment variables (with "Append variables to native environment" option set):
MINGW_HOME C:\MinGW
PATH C:\MinGW\bin;C:\MinGW\msys\1.0\bin
Click "Apply" and then "OK".
This worked for me, as far as I can tell.
If you are using MinGw, rename the mingw32-make.exe to make.exe in the folder " C:\MinGW\bin " or wherever minGw is installed in your system.
Just to clarify the details that Adel's linked eclipse forum covers, here's how I solved this (on OS X):
Note: for me, even though my personal environment (i.e. if in bash, echo $PATH) had /Developer/usr/bin in it, I still had to add it to Eclipse's Environment variables:
Go to Eclipse Preferences -> C/C++ -> Build -> Environment -> Add.. -> "${PATH}:/Developer/usr/bin"
In the case of some other OS, just use the right path where make exists.
If you are using MinGW toolchain for CDT, make.exe is found at C:\MinGW\msys\1.0\bin
(or search the make.exe in MinGW folder.)
Add this path in eclipse
window->preferences->environment
Make sure you have installed 'make' tool through Cygwin's installer.
If you are using GNU MCU Eclipse on Windows, make sure Windows Build Tools are installed, then check the installation path and fill the "Global Build Tools Path" inside Eclipse Window/Preferences... :
Probably there are some files inside C:\cygwin\bin called xxxxxmake.exe, try renaming it to make.exe
I had the same problem.
Initially I had setup Eclipse CDT with Cygwing & was working smoothly. One day there happened a problem due to which I had to reset windows. After that when I opened Eclipse I started facing the issue described above. This is how I solved it.
First I searched that in the error the PATH variable value is same as the PATH variable of windows ( just by manual comparison of both two values ). I found that to be same. Now I realized that it is a PATH problem.
Then started looking for Cygwin whether it is there or not? It was there. I located & found that it exists in
C:\cygwin64\bin>
C:\cygwin64\bin>dir ma*
Volume in drive C is Windows8_OS
Volume Serial Number is 042E-11B5
Directory of C:\cygwin64\bin
16-05-2015 18:34 10,259 mag.exe
13-08-2013 04:57 384 mailmail
11-04-2015 02:56 4,252 make-emacs-shortcut
15-02-2015 23:25 194,579 make.exe
04-05-2015 21:36 40,979 makeconv.exe
29-07-2013 11:57 29,203 makedepend.exe
16-05-2015 18:34 79,891 makeindex.exe
16-05-2015 18:34 34,323 makejvf.exe
07-05-2015 03:04 310 mako-render
18-04-2015 02:07 92,179 man.exe
18-04-2015 02:07 113,683 mandb.exe
13-08-2013 04:57 286 manhole
18-04-2015 02:07 29,203 manpath.exe
24-10-2014 13:31 274,461 mate-terminal.exe
24-10-2014 13:31 1,366 mate-terminal.wrapper
15 File(s) 905,358 bytes
0 Dir(s) 373,012,271,104 bytes free
C:\cygwin64\bin>
Then I simply went ahead & updated the PATH variable to include this path & restarted eclipse.
The code compiles & debugging (GDB ) is working nicely.
Hope this helps.
Go to Project> Properties> C/C++ Build> Environment. You will see three fields, choose PATH. See if the folder containing make.exe is appended to the path or not. Sometimes the change to the System PATH variable (made from My Computer> Properties> Advanced System Settings...) is NOT reflected in Eclipse. This solved the problem for me, hope it helps you too!
Additional hint: If you have multiple projects with different toolchains open, check the build console header for the failing project's path.
I've just spent half an hour trying to fix a build that showed this error because another project with hopelessly outdated toolchain settings was open in the same workbench. Closing the other project re-enabled the build.
I also faced this problem but solved it by installing QT and extract the omnet5.6 folder in C:
I am building a C++ solution with Visual Studio 2005.
Sometimes I open the solution in Visual Studio and build it from within the development environment. Other times I build it from the command line using msbuild.exe. I'm wondering if there is a way that I can determine which of these two types of builds I'm using at compile time (for example, a macro or something like like that). I want to change the path of my output files based on this determination. So, if I'm building from within Visual Studio I would put my output files in FolderA but if I'm building from the command line I would put my output files in FolderB. Is this possible?
Perhaps you can pass in a command-line parameter when building from the command-line that would indicate you are building the solution from the command-line. Otherwise, you can assume you are building from within Visual Studio.
I don't have the answer to your general question, but in order to change the output path, have you thought of adding project configurations ? You could copy project configurations and update the output path of the new ones.
I have just installed Microsoft Robotics Studio 2008 R2, and I must admit that I'm shocked to discover how paths are handled.
First of the studio wants to install itself into my personal profile (this is on Vista):
C:\Users\MyUserName\Microsoft Robotics Dev Studio 2008 R2
I assume this is because during development I have to write files to the robotics studio folder making C:\Program Files a no go.
Then when I create a new robotics project a lot of absolute paths pointing to the robotics studio is added to the project. If I check my project into source control and another developer checks it out onto his machine the absolute paths will not resolve and the project will not compile.
Also, since all services are collected into a single folder in the robotics studio folder developing multiple independent services on a single computer appears to be at least confusing.
Do you have any good strategies for handling this mess?
I have now figured out a way to change a Microsoft Robotics DSS Service visual studio project into something that you can compile and run in you own source tree independent of the installation path of the robotics studio. Here is a description of what you need to do to modify the project:
Add the robotics studio bin path to you PATH environment variable to be able to execute dssproxy.exe without supplying a full path. I have installed robotics studio into the program files folder to avoid accidentially writing files to the robotics studio folders.
Open the Properties page for the project and select the Build tab. In the Output section change the Output path to Debug\bin. For .NET projects it is customary to compile into folders bin\Debug and bin\Release but the robotics hosting service expects to live in a folder named bin and will store data in the folder above the bin folder.
Go to the Signing tab and select a new key in the Choose a strong name key file box. You can either generate your own key at that point or use the sn.exe utility to generate a new key. Or if you have your own policy for creating keys follow that. The sn.exe utility can be found in the tools folder of robotics studio.
In the Build Events tab edit Post-build event command line:
dssproxy.exe /dll:"$(TargetPath)" /proxyprojectpath:"$(ProjectDir)Proxy" /keyfile:"$(SolutionDir)Key.snk" $(ProxyDelaySign) $(CompactFrameworkProxyGen) /binpath:"." #(ReferencePath->'/referencepath:"%(RootDir)%(Directory) "', ' ')
Pay attention to the argument to /keyfile. Enter an expression that locates the strong name key file created in the previous step.
Copy the files DssHost.exe and DssHost.exe.config (or DssHost32.exe and DssHost32.exe.config for the 32 bit hosting service) from the robotics studio bin folder into the project folder and add these files to the project. Set the Build Action to Content and Copy to Output Directory to Copy if newer. Do the same for the manifest file for your service. Actually, the manifest file doesn't have to be in the same folder as the service, but copying it to the output folder enables you to do XCOPY deployment.
In the Debug tab change the Start external program to the DssHost.exe in the output folder of your project. You will have to build the project once to copy the file to the output folder. Clear the Working directory. Set the Command line arguments to
/p:50000 /t:50001 /m:DSSService1.manifest.xml
Change the manifest file name to the proper name in your project. You can modify the port numbers used either here or in the DssHost.exe.config file. If you are running in a protected Windows environment (UAC) you will have to use the httpreserve command to give yourself access to a particular port. You have to run this command as administrator.
Debug settings are not stored in the project file and each developer will have to create personal settings.
You should also update the Release configuration accordingly.
Since I was only interested in the CCR of MS Robotics, I just add these assemblies as a reference to any project I use it with and just be done with it.
This works without any problems. So if you are also only interested in the CCR and DSS part of the studio then this could be your solution
Reinier
we see this problem a lot. The absolute easiest solution is to specify the install directory when installing robotics studio to be "C:\program files\microsoft robotics studio". That way moving code between machines, checking out of source control, etc becomes a lot less problematic.
The other option is to use dssprojectmigration, which is included with RDS. Just run dssprojectmigration against your project directory, and it will correct all the hardcoded paths.