I can't count how many times I've opened a Xcode project instead of a workspace and spent a half hour trying to figure out what I've done wrong because none of the dependancies can be found.
Is there a way to detect this and generate a helpful error message in my compiler prefix?
I could try importing one of the headers that isn't always available, but I'd prefer something more direct and obvious if possible. (Mostly because if I rely on a particular header, that only really checks one package. It also imports the header so I don't need to #import it from my other code.)
You might use a pre-action Build phase script in your scheme to check the build path and take some action if it's wrong. In your workspace, you can specify a custom build path for workspace-wide stuff. If the path doesn't match, you know your target is being built from project only. (It's unfortunate that Apple doesn't provide an environment variable for the workspace and that even workspace-level schemes give the target's project as the project path.) But this is fiddly and seems gross. You ought to feel dirty even considering it, and guilty at having caused me to write it. What would your mother think?
Another (better, IMO) approach is to Manage Schemes when opened as Workspace and change the Container for all schemes to your workspace vs. project-level. This ensures there are no schemes available to build if the project itself is opened. You'll see "No Scheme" and any attempt to build, run, whatever, will give you an error beep.
Related
I'm new on a project and the building is quite slow.
Now I see as a postbuild event the next action for a lot of projects:
<PostBuildEvent>rd "$(ProjectDir)obj" /S /Q</PostBuildEvent>
I've read that the obj folder keeps track of the builds so incremental builds can be faster, so I thought maybe this has something to do with it.
However, nobody in my team know why this is done, the removal of this folder, so I'm a bit hesitant to just remove the build action.
What can be a reason to perform this action?
A couple of things come to mind (all rather questionable by themselves):
Custom build steps in the same, or - God forbid - other project that requires it (for the next build to succeed).
A (misguided) attempt to preserve disk space (since all "precious" is in "bin" after the build you technically don't need "obj").
A (misguided) attempt to implement "clean, clobber, etc."-semantics
One needs more information about the complete build system, other projects, etc. you have in place to find out more or better reasons - if at all ;-)
The single possible reason to perform such kind of action is lack of knowledge about power of MSBuild utility.
I believe that target requirement (if it exist) could be achived another way, which will not omit the incremental build feature.
Try to find the author of that string in VCS you are using, and if author is unavailable or could not answer the question, warn your colleagues and remove it and see what happens.
There is a bug in Visual Studio where if you move the obj directory with the IntermediateOutputPath defined in the project file then the compiler still creates an empty obj directory any way. I do both myself, but with VS2010. If VS2015 has this fixed you may be able to remove it.
I just can't figure out how to do this.
I have a special Build Configuration alongside Debug and Release. (Let's call it Foo)
My CFBUndleIdentifier is com.my-company.our-project.
However, when I build (and archive) for the Foo configuration, I want to use the bundle identifier com.my-company.foo.our-project
Is this possible? Everything I've tried has failed.
I spend much of my day building a white-label product, so I have to do this all the time.
The solution we came up with was to use an Xcode "Run Script" build phase as a "postflight" script.
In your project file, select the target, Build Phases, and then add a new "Run Script" build phase. I renamed the phase to "postflight" and ensured to move the phase to be the last thing done amongst all the build phases.
The essential thing the postflight script does is look for the built .app package, look for the Info.plist within it, and then change the CFBundleIdentifier within it for whatever our present build configuration is set for. Our script does a lot more than just this (other logic, post-processing, resource manipulations, etc.).
I can't provide too many specifics since my setup is customized for me, and yours is obviously customized for you. But that's the basic approach. Hopefully it'll work for you.
Codeblocks cannot find definitions or declarations of some functions in my project.
Question: Is there a way to force a re-scan of the source tree?
I believe that all of the relevant files are included into the project.
(Just checked: it cannot find by name a struct declared in an opened file.)
First, let me give a couple of ways to help C::B find your declarations/definitions.
Although somewhat obvious, you should make sure the function is in a file that is either:
1) part of the project itself (i.e. it should be shown in the projects->workspace window). If you intended it to be part of the project but it isn't there, then go to project->add files and add the file.
2) If you don't want/need the file to be part of the project but you still want to access the declarations/definitions, you need to let the project manager know where to find the file. You can do this in project->build options and set the search directories. Be careful when setting the search directories...you can set it for the whole project or build target (debug or executable).
Note: one common problem occurs when you have multiple projects open in C::B. Even though all your projects are "open", there is only one that is "activated". So, just because you have a file open, it doesn't mean the file is part of the activated project. You can do search-->open files" which will find code in a file if it's open but not in the current active project.
The only way to "re-scan", is to rebuild your project after making changes in the source code or project settings. You may have to restart C::B. If you still can't find the declaration/definition after doing the above, I would suggest you make a sample program and see if it will find the declaration/definition. If it does, then you can check the settings between your project and the sample project. In the worst case, you can copy your code from your project to the sample project. If that doesn't work, you can reinstall C::B and try again. Not fun but sometimes it works.
You can try, rebuilding the project, but make sure at least one other file includes the header for the structure or make sure the header and source file are included in the project.
That the logical follow-up for the my previous question: "How to check all projects in solution for some criteria?"
I was given quite a good answer to use CustomAfterMicrosoftCommonTargets, CustomBeforeMicrosoftCommonTargets. They do work, so I decided not to stop in the middle.
Issue is that I don't want machine-wide tasks. It's not a good idea neither for me (it will affect other builds. sure, this can be handled, but still), nor for my teammates (I don't want to let them put something in system folders... ), nor for build server.
What is needed: solution to be built from scratch out of source control on clean machine with either Visual Studio or MSBuild.
It appeared that Custom*MicrosoftCommonTargets are regular properties.
So, how to specify this property? It works pretty fine when to set it from command line.
That's strange, but it appears that bit of magic present here: property passed as command line parameter to one build is transitively passed to all nested builds!
That's fine for build server. But this won't work with Visual Studio build. And even declaring solution-level property won't help: neither static, nor dynamic properties are transfer to nested builds.
...I have a hacky idea to set environment variable on before solution build and erase it on after. But I don't like it. Any better ideas?
I use a bit different technique then #Spider M9. I want that all projects in solution tree/all subdirectories from current directory use extended build throw Custom*MicrosoftCommonTargets. I don't like to be forced to change every new project to import custom targets/props.
I place special file, let's say msbuild.include, in the root directory and my custom targets loader for every project tries to find it in ., ..\, ..\..\, and so on. msbuild.include contains flags that triggers execution of custom actions. If loader can't find this file it disables loading all custom targets and stoppes. This gives me ability to use my build extensions with projects from work repositories and to not use with opensource projects.
If you are interested in I can publish loader. It's a pretty simple and elegant solution.
For example I can sign any assembly in all projects in all subfolders with my key.
I always set up every project to import a standard .props file. Use the GetDirectoryNameOfFileAbove property function (see MSDN) to find it. Do this as the first line of every project file. Once established, you can redirect from that file to other imports. Another trick is to have that standard import (that would obviously be under version control) import conditionally another .props file only if it exists. This optional file would not be in version control, but is available for any developer to create and modify with their own private/temporary properties or other behavior.
I am trying to set up Xcode for a project which contains multiple executables and static libraries. I have created multiple targets and set up the linking and dependencies, and initially everything works great. The catch...
This is an existing project which already has Visual Studio and Makefile builds. Those builds put the libraries in a lib/Debug directory and the executables in bin/Debug. So in Xcode I changed the Build Products Path to "lib" and "bin" respectively (so we can use one set of documentation for all of the platforms). This puts the compiled targets in the right place, but completely breaks both the linking (Library not found) and the dependencies.
I can fix the linking by adding $(SRCROOT)/lib/Debug to the Library Search Paths for each executable (but it feels like Xcode should be able to figure this out on its own, which makes me think I'm doing something wrong).
But — I can't figure out how to get the dependencies working again. If I change a library source file, the library will rebuild but not the dependent executables. If I force a build of the executable Xcode returns success without doing anything; it thinks the target is up to date. If I clean the target and then rebuild it works.
So, any ideas here? Is Xcode being fundamentally stupid in this regard, or is it me (I'm leaning toward the latter)?
Update: I've posted a sample project to demonstrate the issue at http://share.industriousone.com/XcodeDepsIssue.zip. Build it once, then modify MyStaticLib.c and build it again. The executable will not relink (and it should). Many thanks for any help on this one.
starkos, thanks for publishing your conclusion. It validated my experience as well. This situation really screwed me, so it was nice to know I wasn't just missing something.
I did however discover a workaround that avoids creating multiple projects or keeping the library and its dependent in the same directory. It is a hack, but it does work here.
I know it's a bit late but better than never.
For the dependency library, add a "Copy Files Build Phase", with Absolute Path as the destination, and the path text field should be the directory where the DEPENDENT target lives. Then click on Products, find the dependency library (will end with .a), and drag it into the "Copy Files Build Phase." If you now build, this will put the library into its own directory like before and THEN also copy it into the dependent's target directory.
For the dependent, you can now remove the dependency's output directory from the Library Search Paths. This will cause it to find the library copy. If you do this, the dependent will indeed be relinked each time the dependency .a is relinked.
The negatives are, of course, the extra time for the copy, and the necessity to specify (in the Copy phase) the target directory for each dependent of your library. Beats the hell out of the alternatives though....
Xcode doesn't automatically set up dependencies based on use of build products; you have to set up explicit target dependencies yourself.
Project > Edit Target Settings, General tab, + button, add any targets that are prerequisites to building the selected target. That should get you going again.
I've researched this some more and the answer is no, Xcode 3.x doesn't track dependencies between targets that live in different directories. You can work around it by giving each library its own project, and adding each of those to a master project. Or you can keep all of your targets in one directory. Pick your poison.
Here is my solution for this weird behavior in xcode 4.3.1. You have to add build pre-action in scheme:
rm -f ${BUILT_PRODUCTS_DIR}/${EXECUTABLE_PATH}
and choose which build settings to use for this script. Each time before build, target executable will be removed and rebuild completely. It helped for me, and i hope it helps you.
NOTE: Have tried to put this script in project build phase, and result was negative - debugger could not connect process to start debugging.
Good luck!
OK, it would help to have the text of the Linking... build line that's failing. But a couple of things:
1) You shouldn't be linking to anything in $(SRCROOT). That's your project sources. The two places to find things to link are $(SYMROOT) (the Build Products directory) or $(DSTROOT) (the Installed Products directory).
One thing you could do is to have a common Build Directory, then use 'xcodebuild install' action to install the products in the Installation Directory. The other is to use a Copy Files build phase to copy them after building, so you can link against them in $(SYMROOT) but still have them where your Windows compatriots expect them.
THere is probably a way to set up the per-target build products directories correctly, but I'd really have to see the project itself to figure it out.