With visual studio there is an start menu option open a terminal window with all of the paths and environment variables setup to use the compiler.
Is there an equivalent for XCode or is there somewhere I find out what needs setting for this to work?
I am trying to get the boost libraries compiled but am just getting a tone of errors related to simple stuff. I have set some some of what I think should b required (include and lib paths) but I am obviously still missing some.
Martin
Xcode uses gcc and llvm-clang. So the environment variables settings are the same as those.
But if all you want is to have boost available to your project, it may be easier to just install MacPort and build/install boost with it: http://www.macports.org/ports.php?by=name&substr=boost
MacPort supports many, many, many tools and libraries. It will make your life developing on OS X a lot easier.
It sounds like you're really asking about build settings -- the variables that are available at compile time to define things like paths and options. You can set these on a per-project or per-target basis in the Build Settings pane. Select either your project or one of its targets and click on Build Settings. If you want to define your own settings, scroll to the bottom of that pane and look for the "User-Defined" section, where you can add your own settings.
If you want to set environment variables (and arguments) that will be in effect when your program is running, hold down the Option key and choose Product->Run..., at which point you'll get a window that allows you to define environment variables and arguments.
Related
I try to use Xcode (v.7.3.1) for my C++ project (build system - make), but the experience is quite poor (and it was always like that since old versions like v4 when I started using it) - code completion doesn't work, color syntaxing works oddly (no coloring sometimes, or partially colored code), no "jump-to-definition" functionality, can't switch b/w header/source files with shortcuts. Basically, it's just a text editor where I have to use "Find" and Cmd+Shift+O all the time.
Is this intentional and Xcode will never get any proper support for C++ projects with external build system (make) or am I misconfiguring my project? How can I re-index files in the project? How can I make code completion work?
Thanks,
I believe there is a way to use Xcode with makefiles by adding an external build target, file->new->target->External Build System.
This is an older tutorial but the steps may be worth looking through: http://web.ist.utl.pt/jose.alberto.coelho/mac/MakefilesXcode.pdf
I've never had a problem with the syntax highlighting, but I remember the refactoring support being limited for C++ in some ways.
So, I ended up using this workaround: even though, I use external build system, I create Console Application project in Xcode and choose C++ language in settings. Then, I simply add my source files to the project (just drag folders from the Finder window) and then manually create project targets of type External Build System as I need. I don't use default target and don't use generated main.cpp file at all.
My files get indexed with no problems. I'm also able to debug code as I used to.
I still think Xcode developers should review indexing process for the projects with external build system...
Thanks for all the insights though!
hey the title pretty much says it all. i have been trying different methods from internet sources, but whenever i try something goes wrong..this is where i got Box2D
in cMake, i get a bunch of errors when building it(i was going through the steps in the readme.txt, but onfortunately, theyre for Visual C++...)
so im wondering hot to set this up as i guess a library (.lib or .a) and use it in my project(my friend passed me his library and when i loaded it in and tried #includeing the box2D headers, they didnt read at all(i got a list of undefined errors) also his box2d was i believe made for linux/unix so i think thats the reason...)
if anyone can help provide some steps that would be nice.
thanks for reading.
Assumptions:
You have installed cmake.
You have installed Code::Blocks/MinGW to C:\codeblocks.
You have downloaded Box2D and extracted it to C:\Box2D_v2.1.2.
If any of those are wrong, modify the paths to match what you have.
Start->Run->cmd.
Navigate to the Box2D "Build" folder:
cd C:\Box2D_v2.1.2\Box2D\Build
Create the makefiles:
cmake -G "MinGW Makefiles" ..
Do it:
mingw32-make
This will throw some warnings, but should work almost completely. Then, near the end, it will error trying to compile the Testbed. AFAIK, there is no way to compile the Testbed using MinGW (you have to use Visual Studio, I believe). Luckily, an .exe of it is available on the Box2D site.
In the Box2D\Build\Box2D folder, there should now be a file called libBox2D.a. Copy this file into C:\codeblocks\mingw\lib.
Copy the Box2D\Box2D folder (the one containing Box2D.h) into C:\codeblocks\mingw\include.
[Thus, after this step, you should have a file C:\codeblocks\mingw\include\Box2D\Box2d.h, and NOT C:\codeblocks\mingw\include\Box2d.h]
And that's it. You should be able to compile and run the "Hello Box2D" example. Don't forget to link to the library.
[EDIT]
From the looks of your error, I'm going to guess that your MinGW Path environment variable is not setup correctly. Which is unusual, since when you install Code::Blocks/MinGW it usually sets it for you, I believe.
Anyway, (these steps may vary slightly depending on your version of Windows):
Right-click on "[My] Computer"-> Properties -> Advanced System Settings
Click "Environment Variables"
Depending on which Windows you have, you may see User Variables and System Variables, or it may be just one group (I can't remember the name). Anyway, create a new System Environment Variable called MINGDIR, with the value C:\codeblocks\mingw or wherever you installed it to. Then, find the variable called Path (or PATH) and append this to the end: C:\codeblocks\mingw\bin. Put a semicolon at the end of the previous entry, and do not use a space.
Also make sure that C:\CMake\bin is present in either the System Variable called Path, or the user variable called Path. If not, append it to the end.
I think that's it.
I'm trying to design an SConstruct file for an embedded system project. The compiler on my machine is at "C:\Program Files\IAR Systems\Embedded Workbench 5.4\arm\bin" I would like the build system to try to locate the toolchain even if there is another verison of Embedded Workbench installed, or if the user has chosen to install it elsewhere.
I'd also be interested in strategies used in makefiles or ant files since they are probably useful here as well.
What are some strategies for doing this? Do I have options other than searching the Windows registry or looking for "C:\Program Files\IAR Systems\Embedded Workbench *\arm\bin"?
The simplest solution is to use an environment variable. You still have to set that up manually for each build host, but the build system need only refer to the environment variable, so can be common for all build hosts.
For example in your case you might have:
EWBARM_V0504="C:\Program Files\IAR Systems\Embedded Workbench 5.4\arm\bin"
And similar for other versions installed, and then in your build system you would use %EWBARM_V0504% in place of the path. The worse that will happen is if the variable does not exist the build will fail, which is preferable to using the wrong compiler, and easily fixed.
Since different versions of toolchains may have different bugs and/or features, silently falling back onto different sets of tools is probably a bad idea. When I've supported multiple tools versions on a single project, I usually have the version number assigned via a makefile or the environment. Then you can pass -D TOOLS_VERSION=$(TOOLS_VERSION) to your compiler and use that value to key bugfixes and workarounds you need for particular versions of the tools. This system makes it clear which tools you want to support, while still making it easy for other developers to switch tool versions by making a single edit.
The nice thing about SCons is you have all of python at your disposal. So you can use win32.winreg to look in the registry, or glob around in sets of paths, whatever works for you. And of course you can have a command-line option or an options file to override the autodetection. Then once you've found your tool of choice, you have basically two ways to make SCons use it: either prepend the tool's dir to env['ENV']['PATH'] (you can use env.PrependEnvPath for that), or just use the tool's full path as the value of your $CC (and set $LINK, $SHLINK etc. appropriately too).
I usually make a TOOL_MYCOMPILER function that takes an env and sets it all up for use with the compiler and its toolchain (cpp, linker, whatever). It keeps things cleaner in your SConstruct/SConscript.
I have a number of native C++ libraries (Win32, without MFC) compiling under Visual Studio 2005, and used in a number of solutions.
I'd like to be able to choose to compile and link them as either static libraries or DLLs, depending on the needs of the particular solution in which I'm using them.
What's the best way to do this? I've considered these approaches:
1. Multiple project files
Example: "foo_static.vcproj" vs "foo_dll.vcproj"
Pro: easy to generate for new libraries, not too much manual vcproj munging.
Con: settings, file lists, etc. in two places get out of sync too easily.
2. Single project file, multiple configurations
Example: "Debug | Win32" vs "Debug DLL | Win32", etc.
Pro: file lists are easier to keep in sync; compilation options are somewhat easier to keep in sync
Con: I build for both Win32 and Smart Device targets, so I already have multiple configurations; I don't want to make my combinatorial explosion worse ("Static library for FooPhone | WinMobile 6", "Dynamic library for FooPhone | WinMobile 6", "Static library for BarPda | WinMobile 6", etc.
Worse Con: VS 2005 has a bad habit of assuming that if you have a configuration defined for platform "Foo", then you really need it for all other platforms in your solution, and haphazardly inserts all permutations of configuration/platform configurations all over the affected vcproj files, whether valid or not. (Bug filed with MS; closed as WONTFIX.)
3. Single project file, selecting static or dynamic via vsprops files
Example: store the appropriate vcproj fragments in property sheet files, then apply the "FooApp Static Library" property sheet to config/platform combinations when you want static libs, and apply the "FooApp DLL" property sheet when you want DLLs.
Pros: This is what I really want to do!
Cons: It doesn't seem possible. It seems that the .vcproj attribute that switches between static and dynamic libraries (the ConfigurationType attribute of the Configuration element) isn't overrideable by the .vsprops file. Microsoft's published schema for these files lists only <Tool> and <UserMacro> elements.
EDIT: In case someone suggests it, I've also tried a more "clever" version of #3, in which I define a .vsprops containing a UserMacro called "ModuleConfigurationType" with a value of either "2" (DLL) or "4" (static library), and changed the configuration in the .vcproj to have ConfigurationType="$(ModuleConfigurationType)". Visual Studio silently and without warning removes the attribute and replaces it with ConfigurationType="1". So helpful!
Am I missing a better solution?
I may have missed something, but why can't you define the DLL project with no files, and just have it link the lib created by the other project?
And, with respect to settings, you can factor them out in vsprop files...
There is an easy way to create both static and dll lib versions in one project.
Create your dll project. Then do the following to it:
Simply create an nmake makefile or .bat file that runs the lib tool.
Basically, this is just this:
lib /NOLOGO /OUT:<your_lib_pathname> #<<
<list_all_of_your_obj_paths_here>
<<
Then, in your project, add a Post Build Event where the command just runs the .bat file (or nmake or perl). Then, you will always get both a dll and a static lib.
I'll refrain from denigrating visual studio for not allowing the tool for this to exist in a project just before Linker (in the tool flow).
I think the typical way this is done is choice 2 above. It is what I use and what I have seen done by a number of libraries and companies.
If you find it does not work for you then by all means use something else.
Good luck.
I prefer 2 configurations way.
Setup all common settings via 'All configurations' item in a project properties windows. After it separated settings. And it's done. Let's go coding.
Also there is very good feature named 'Batch build', which builds specified configurations by turn.
Multiple projects are the best way to go - this is the configuration i have most widely seen in umpteen no of projects that i have come across.
That said, it might be also possible to implement the third option by modifying your vcproj files on the fly from external tools(like a custom vbscript), that you could invoke from a make file. You can use shell variables to control the behavior of the tool.
Note that you should still use use visual studio to make the build, the makefile should only launch your external tool if required to make the mods and then follow that by the actual build command
I use Visual Studio 6.0 (Still) due to issues that are preventing us from Migrating to VS2005 or newer. Rebuilding causes severe issues (everything breaks)... so many of us are considering lobbying a migration to GnuC++ moving forward in a structured way to eventually get us off of licensed Visual Studio products and onto Eclipse and Linux.
In Unix/Linux it is easy to build for all configurations.. so I can't believe what a time and productivity sink it is to try and accomplish the same task in Visual Studio. For VS6.0 I have so far found that only having two separate projects seems to be workable. I haven't yet tried the multiple configuration technique, but will see if it works in the older VS6.0.
Why not go for version 1 and generate the second set of project files from the first using a script or something. That way you know that the differences are JUST the pieces required to build a dll or static lib.
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.