I've got an XCode 4 project that has an additional dependency project in it. The dependency project creates a static library I need for the major project.
I'm trying to add the library from the Target->Build Phases->Link Binary With Libraries, choosing the static library in my workspace.
Problem is every time I do that, the build settings "Library Search Paths" is appended a path to the build of the iphoneos build. When I try to compile for simulator, that file is ignored as it not meant for i386 architecture and the build fails.
I've been searching like mad, not understanding what I'm doing differently. Everywhere I look, it seems like XCode should be doing some magic to link simulator with simulator and device with device - But for me it always adds the specific path to either the device or simulator.
(I've tried using two targets to differ them, and that worked, but it's not an ideal solution at all. I have to change 2 targets everytime instead of 1.)
Hope I was understood,
pleeeaaaaase help :)
Oded.
My colleague found the answer eventually -
In XCode 4 the default is to build all projects to a shared building folder. Me being fixated with XCode 3, switched it to the old method in which the build folder is in your project folder.
Turns out switching XCode to build in a single unique place, allowed the magic to happen to and to the corresponding builds be built together. I've been told it's exactly what it's meant for, but have no link to the reference.
XCode Menu -> Preferences -> Locations -> Build Location:
- Place build in derived data location (recommended)
- Unique subfolder
Cheers,
Oded.
Related
I have an issue with custom libraries that reference headers in other custom libraries.
This is under Eclipse (2020-03) with the 9.11 CDT - Arduino Plugins. (So the latest Version at this time)
Until now I have been using Sloeber, which included all include paths from all custom libraries so everythig was building fine. But with the latest Eclipse/CDT version sloeber does not work anymore. Since it should not really be necessary anymore anyway, I am trying to get my projects to build with just the CDT-Arduino Plugin(s).
Simple projects are Building fine, but more complex have issues…
The build process (makefile generation) seems to scan though the libraries directory, because I can see all the entries in the makefile to build the things it findes in there. But I one of these libraries referneces a header of another one it failes to find it.
Of course I could just edit the include and make it relative, but since these are imported libraries I prefer not to make changes in the code.
With the Arduino plugin there is also no configuration for include paths etc in the project properties any more :-( Normally I would have added the include path there, but the arduino Plugin seems to want to do it all by itself...
Any idea, how I can add the required include paths? Is there a way to do this in the makefile.ini?
I found a different and better way to add custom libraries, which also solves the include path problem. Sadly there is no documentaion about this.
Anyway, it is very simple, just copy the library to the …/.arduinocdt/libraries/ folder. The custom library must contain a library.jason and library.properties file. When opening the Arduino download manager, you can see the new lib and ýou can add it.
Eclipse will read the library version from the json/properties and copy the data in the correct form in a sub directory with the version number.
For libraries added this way, all includes/headers will be found without Problems including libraries referencing other libraries.
I'm modifying a simple example project (blinky) from the nRF SDK. I added a header file and a .c file in a new folder inside the project directory then added that path ./lib to the common preprocessor user include directories. I then included the header to main.c.
I can compile the new library on its own but when I build the whole project, I get Build failed error with no stated reason to follow up.
Here is an image of that:
Does anyone here know how to beat this?
I haven't used Segger Studio specifically, but it seems to be the CrossWorks IDE underneath.
In CrossWorks, you have to do the following:
Download & install all relevant libs from inside the IDE, under Tools -> Packages -> Install packages. Grab your specific target MCU as well as any specific boards or libraries you'll be using. In case some needed lib is missing here, you will get very weird errors.
In the project, click on the project name itself in "project explorer". Then in the properties window, check settings (this is a bit different in different versions of CrossWorks, might have to right click and pick properties in older versions). Under "user include directories" you should have something like this:
$(DeviceIncludePath)
$(TargetsDir)/NameOfMCU/Include
$(PackagesDir)/CMSIS_4/CMSIS/Include
$(ProjectDir)/NameOfDirectory
Where "NameOfMCU" is the name of the MCU family used, CMSIS should be there in case you are using any ARM, "NameOfDirectory" is the name of your custom directory (you can add several).
Also, get the debug build working first, before switching to release build.
I have a Visual Studio 2013 solution with several projects in it. There's a Core project and Engine project, which compile to static libs, and a final Game project which links those libraries.
If the Engine has a compile error in it, then that project fails to build. However, Game will still attempt to build and link, presumably using the existing / old Engine library file.
So, even though my build has a compile error, it still produces a final EXE. Is there any way I can stop this?
EDIT: Here are the options I am using to reference the first two projects from the final one. Perhaps I am doing something wrong here?
There seem to be StopOnFirstBuildError extension for that purpose. Found reference to it in the feature request
Set proper dependencies in your projects: usually all you need is to add references, this way if one of dependent project fails final exe won't build as it wouldn't have all required references.
In your case it seems like you copy some libraries to some other location and then use these copied libs for linking. This would definitely lead to problems like the one you describe if your final exe doesn't use references but has manually configured input libraries in linker settings.
For example, if you use VS 2013 (or any recent version), and have a few static libraries and some executable that depends on them you should do this:
remove explicit libs from "Additional Dependencies" from linker settings of your executables and dlls.
remove explicit dependencies from project settings if you set anything manually (for simple cases you don't need to set these).
add your lib projects to references of your executable or dlls that use these (this properly sets all dependencies, linker inputs etc if you use default VS project settings):
If your Core and Engine are static libraries, then do not make Engine dependent on Core even if Engine uses Core, this way VS can build them in parallel. If Engine is a dll then add Core to References of your Engine project and add references to Engine to your Game project. If Core and Engine are static libs, then simply add references to Core and Engine to your Game project, nothing else is needed.
Try this sample TestGame VS project.
First build TestGame project, try to run it.
Go to engine.cpp and introduce some error in that file.
Now build TestGame project again. VS first tries to compile TestGameEngine project and this fails and ends entire build process without even attempting to build TestGame project.
At this point TestGame project still has and old binary that was left from previous successful build and if you try to run TestGame it will ask if you want to build it (as it's outdated):
If you click "No", it will run old binary. If you click "Yes" it will try to build TestGame project again (which will fail again). If you check that box "Do not show this dialog again" and click "No" Visual Studio won't try to rebuild an existing binary even if it's out of date, and will run existing binary and won't ask again about that.
If you click "Yes" after it fails to build updated binary of TestGame it will ask if you want to run old build:
If in this dialog you also check that box to not ask again you'll probably get that behavior that you describe where VS tries to use last successful build. All you need to do to "uncheck" check check boxes now. You can do that in options (Tools -> Options -> "Project and Solutions" -> "Build and Run"), see the screenshot:
I am trying to embed the mono runtime in a C++ OS X console app (Will be used for scripting logic in a home-brew game engine, much like Unity3D). I am using XCode as the IDE and am failing spectacularly at linking the mono libraries. I come from the dark side (Windows) and am new to mac libraries and XCode.
I have successfully built mono and referenced the header folder but get a slew of APPLE-MOCH-O linkers errors no matter what .a I add to the project. I have also successfully built this sample project https://github.com/inkdev/Embedded-Mono-Sample for windows. The mono site on the topic http://www.mono-project.com/Embedding_Mono is confusing and of little use to me.
Help would be hugely appreciated.
EDIT:
If I remember correctly, I followed these commands http://www.mono-project.com/Compiling_Mono_on_OSX and got the source from here: https://github.com/mono/mono/tree/master/mono, and used make and make install. I added the /mono/include... folder to XCode's "Header Search Path" and that resolved all the unfound includes. Under /mono/lib/ I have tried several different *.dynlib files ( drag them into XCode ) but none have worked. libmono-2.0.1.dylib says "..file was built for unsupported file format..", and libmonoboehm-2.0.dylib simply says "...Undefined symbols for architecture x86_64..."
To anyone in the future who wants to compile and link the Mono runtime in XCode, here are the steps I followed.
Grab/Extract the latest *.tar.gz from: http://download.mono-project.com/sources/mono/
Follow these instructions: http://www.mono-project.com/Compiling_Mono_on_OSX
Open up /mono and drag /mono/lib/libmono-X.X.dylib into your XCode project ( Make sure it is adde to target ).
In XCode, select your project, select your target, select Build Settings.
Search for "Header Search Paths" and add: /mono/include/mono-X.X
Use this source code to test it out: https://github.com/inkdev/Embedded-Mono-Sample
You may need to copy /mono/etc/mono/X.X to /mono to fix a runtime error.
All your monos are belong to us now, enjoy.
I am quite used to Linux development and Makefiles, and started using (Windows and) Visual Studio not so long ago.
What I want to do is (I think) quite simple, but I can't seem to find how to do it using Visual Studio.
I have to write an application, which I can divide into several independent sub-parts. I want to work incrementally, and create several projects that together with a main file will end up with my full project.
What I basically want is to be able to write a small project, have a main for it so that I can fully test it, and use it as a dependency for the next project. In this case, the smaller main would be deactivated (or I can comment it), and I would just change the startup project.
If I find a bug in a subset while writing my bigger software, I could just change the startup project and solve it at a smaller scale.
Well, that's what I do all day long in Python and Java.
I tried to create new projects into my project, but I always end up having linking problems, where my main projects knows about the files in the sub projects, but not the smaller ones, etc. . .
So, is there a guide somewhere I can find to work this way ?
Thank you
For individual projects:
Every individual project property sheet has a C++ options page. Here you can specify the 'Addional Include Directories' in a comma separated form.
Similarly, there should be a property sheet for Linker where you can specify the 'Addional Include Dependencies' and the names of the libraries it depends on.
For linker dependencies of the main executable:
Go to that main project, go to its properties, go to common properties and select 'Framework and References'. This should give you a list of all the projecs that are in your solution. Keep adding them and Visual Studio should add the right linker flags automatically for you.
Sorry, have no access to the computer now else would have provided exact steps. Visual Studio can get tricky sometimes but once you use it, you'll be amazed by what it can do for you. Personally, I love it.
Hope this helps.
Thanks to Vaibhav, I was able to find a solution:
I had to :
change subproject type to lib instead of exe
Add the subprojects as project dependencies in the main project (this just sets the build order)
Comment out the main of my subprojects, to keep only one active.
Add each subproject include directory in the include repos of the main project, so that the compiler can find the header files
Add the general directory as a dependency for the linker (in this case, it is not the debug/release folder of the subprojects, but the output directory of the complete project).
Add the names of the lib files of the subprojects in additional dependencies of the linker of the main project.
To make it simple, the project dependencies capability of VS2010 just changes the order in which the projects are built. . . I miss Eclipse.
If I find a bug and want to test on of the subprojects, I have to :
change the startup project to be the subproject I want to change.
uncomment the corresponding main
change the project type to be exe instead of lib to be able to compile it.
Debug, and do everything back again to continue working on my main project.
Quite boring, don't you think ?
Looks like you trying to do manual unit testing. Use something like Google.Test. You need to make test project for every lib.
We have directory with static libs projects. Another directory with tests projects. Every test solution contains one exe project and few existing lib projects. Every project have configured dependencies. You dont need to set additional dependencies of the linker manually (paths are evil, out dir for the lib file will be taken from project settings), open project properties with right mouse button, Common properties, Add new reference and select lib project. You only need to set additional include dirs.
When you find new bug - just open test project for the library with bug, add code which cause the bug, fix it, and be happy (and sometimes run all test). And even better - use TDD.