I installed Mogenerator. Now what do I do? How do I use it?
The first problem I have is that I have no idea check the chekbox "run scripts only when installing" for mogenerator or not ?
To which checkbox exactly are you referring? One on a "Run Script" build phase within Xcode?
Mogenerator is a tool for generating model classes from your Core Data model. Since it does not yet have an Xcode 4 compatible plugin you want to run it as a command line tool whenever you make changes to your Core Data model.
You could do so in a Run Script build phase. In that case you would probably not want to wait until you are installing the app as you would then not have access to newly added properties on your model classes until you ran an install build. Instead you really want the script to run when you have made any changes to your Core Data model and before you start compiling your project.
I find Core Data changes to be relatively infrequent so I might choose to run mogenerator manually when I make a change rather than rerunning it unnecessarily on every build. I'd probably save my mogenerator command line setting in a shell script or rake task but alternately you might follow John Blanco's example and create a new build target containing only your mogenerator Run Script build phase so you can run it on demand from within Xcode: http://raptureinvenice.com/getting-started-with-mogenerator/
Related
I am trying to follow the instructions for contributors here:
https://bazel.build/contributing.html
I have a successful build off of master (i.e. bazel build //src:bazel), but the doc suggests also "you might want to build the various tools Bazel uses." I am trying to do that, for example:
cd src/java_tools/singlejar
bazel build //...
but it fails with:
ERROR: /Users/.../bazel/third_party/protobuf/3.2.0/BUILD:621:1: no such target '//external:gtest': target 'gtest' not declared in package 'external' defined by /Users/plaird/scone/public/bazel/WORKSPACE and referenced by '//third_party/protobuf/3.2.0:test_plugin'.
Do I need to build gtest locally, and then add it to the WORKSPACE file?
bazel build //..., no matter where you invoke it, will build everything in the project. It looks like what you probably want is bazel build //src/java_tools/singlejar/..., which will build all targets under that directory.
In general, though, you probably don't need to compile singlejar separately. I've been working on Bazel for several years and 99% of the time you don't have to build the tools separately.
In terms of the error you're getting, it would be nice if we could get //... building, but it hasn't been a huge priority. The protobuf code build is weird and I don't recommend trying to debug it, just jump into whatever you want to actually work on.
I have been using fastlane (2.24.0) gym for IOS builds (Xcode Command Line Tools xcode-select)
Is there a built-in method which I could use to ensure that I am building from a stable environment? I like to submit the build and use the time while it is building to carry on working.
I do not want to build from the git repository but from my own machine.
I could copy the directory either manually or in the fastfile script and build from there but I thought perhaps that there was a method or parameter I could use to avoid this step.
you mean that you want to keep on editing the source code while gym is building your app? - saddly i don't see any option to this, without copying the whole project folder.
if you just wan't to ensure the build fragments to not overlap you can use/set derived_data_path on gym
however there are a couple of issues on running xcode (building) - multiple times in parallel.
the only sane way to build and carry on working is to offload the building/packaging process to any sort of CI.
We are looking for ways to stop a build if it is being built for release and contains strings that reference "localhost" or containing "10.0" or other rules. does xCode have a way of enforcing these rules?
You can add a custom shell script build phase to your project.. you can run whatever shell script you want in there. You can also inspect the plethora of build environment variables, including one which should tell you if you are building for release or debug.
$ ant clean compile notexist install
Here I get BUILD FAILED because notexist doesn't exist as a target, which is expected. But is there anyway to just ignore or skip unknown targets? Or maybe map unknown targets to a known target (which would be a no-op for me)?
Background
We are using Atlassian Bamboo for our CI server, and whenever we want to add an ant target to our build, we run the risk of breaking older branches of code. This is because if we run an old build through our CI, it may not contain the target and therefore fail. Thus we are reduced to editing the build.xml file, and either use depends or <ant>, but this doesn't give us the flexibility we desire.
Example
Today we have:
ant clean selenium.tests
We want to add a new target to test our REST services. Target is rest.tests. Thus, I want my command to be
ant clean selenium.tests rest.tests
But for old branches, rest.tests doesn't exist yet. Our solution up to now has been to add rest.tests as a dependency of selenium-tests (since our build.xml is under version control), but this means we can't run selenium.tests by itself.
In hindsight, we should have just created a proxy target, such as integration.tests (we already use test for unit tests) which would delegate to both of these two targets. But unless there is a solution to my original question, we can't even add integration.tests to the CI.
You may have to invoke ant programmatically. Discussed here in Running ANT Programmatically Through Java
The org.apache.tools.ant.Project provides list of targets and way to invoke it
I don't think there is a way to test that a target (rather than a file) exists as you call it. My suggestions are:
How often do you build old versions which have missing targets? If it sufficiently infrequent that you can take the pain of manually commenting out those calls in the CI config?
Can you limit your CI calls to a tidy set which will generally be there: clean, build, test, dist etc?
Do you need to split the CI config into multiple jobs? If you really need targets which aren't there in some versions maybe you have radically different versions of your product that merit separation into different CI jobs. Then it won't make sense to build the job for which the target doesn't exist.
Is it possible to execute a script within a custom Xcode 4 project file template? I am not referring to a Run Script within the target build phase but a script that is executed once the template is chosen and prepares the project itself.
I am trying to create a template that forces the addition of a (number of) git submodules. To do so, I envisioned to run a script that is executed once the user creates a project file from my custom template. So far, my research did not succeed in finding a way to run a script once the template is used.
You could try adding a .gitmodules to a project template… no idea if that would fly under Xcode's templates.
If that fails, then, no -- but you can just add the .gitmodules file to the directory (or write a script), and the process should be quick and painless despite no direct support from the ide.
You might even take a middle of the road approach, where the project contained a script (PROJECT_ROOT/config_modules.sh) to add these modules to the repo at that directory. Then create another script to search, exec, and delete the config_modules.sh, once you have created all those projects.