# FAQ Or rather, stuff I would ask, if I hadn't written it myself :) ## Where is what ? * `.bootstrap` is the bootstrap configuration of the repository. * `.bootstrap.auto` is generated by mulle-bootstrap fetch, it contains information recursively collected from dependent repostiories, that have their own .bootstrap folder. * `.bootstrap.local` contains local settings you can use to override settings in .bootstrap and .bootstrap.auto. You may create it manually, but you don't have to. * `~/.mulle-bootstrap` contains some global customizations. This becomes autogenerated when using brew stuff. * `build/.repos` contains intermediate files generated by the build, which can be safely thrown away at any time. * `dependencies` contains the produced headers, libraries and frameworks * `/usr/local/libexec/mulle-bootstrap` contains scripts for mulle-bootstrap ## Where is what in .bootstrap ? * Files in `.bootstrap` itself are used for fetching dependencies and some configurations. * Files in `.bootstrap/config` are rarely used options, to change mulle-bootstrap behavior. * Files in `.bootstrap/settings` are used for building dependencies. Here you find compiler flags, targets, sdks et.c. ## Where is what in .bootstrap.auto ? * Files in `.bootstrap.auto` are an amalgamation of .bootstrap and the contents of .bootstrap of the dependencies. * .bootstrap/config should not exist * Folders in `.bootstrap.auto/repos` are the settings inherited from .bootstrap. ### How are multiple value settings separated ? Separation is done by newline, not by space. ```console mkdir -p ".bootstrap/settings" 2> /dev/null echo "Debug Release" > .bootstrap/settings/configurations # WRONG echo "Debug Release" > .bootstrap/settings/configurations # RIGHT ``` ### Can I change the build folder from build/.repos to something else ? Better not. You can set it with "build_foldername". But beware: ><font color=red>mulle-bootstrap assumes that it can just **rm -rf** the folder, so choosing `~` or `/tmp` as a build folder is not a great idea.</font> ```console echo "you_have/been_warned" > ~/.bootstrap.local/build_foldername ``` ### I specified SKIP_INSTALL=YES in my Xcode project, but stuff gets installed nonetheless ? Because this SKIP_INSTALL=YES is the default unfortunately and lots of project maintainers forget to turn it off, **mulle-bootstrap** sets this flag to NO at compile time. If you know that SKIP_INSTALL is correctly set, set "xcode_proper_skip_install" to "YES". ```console mkdir -p ".bootstrap/settings/{reponame}" 2> /dev/null echo "YES" > .bootstrap/settings/{reponame}/proper_skip_install ``` ### I changed something in .bootstrap but nothing happens ? This can happen, when a .bootstrap.auto was created. The easy solution is to say `mulle-bootstrap clean dist`. ### My Xcode project's headers do not show up ? Check that your Xcode project has a **Header Phase** and that the header files are in "public". ### I have a depencency on another library in the same project. The headers of the dependency library are in `dependencies/usr/local/include`. What now ? **mulle-bootstrap*+ can't manage xcodebuild dependencies, so you have to help it. Specify the targets you want to build or set the proper dependencies in the xcode project. ### I build an aggregate target and the headers end up in the wrong place mulle_bootstrap has problems with aggregate targets. Built the subtargets individually by enumerating them in ".bootstrap/settings/{reponame}/targets" ```console mkdir -p ".bootstrap/settings/MulleScion" 2> /dev/null echo "MulleScion (iOS Library) MulleScion (iOS Framework)" > .bootstrap/settings/MulleScion/targets" ``` ### mulle-bootstrap does not do what I want ? Check out the SETTINGS.md file for help about tweaking mulle-bootstrap. As an example, here is how to specify what target to build. Put the target name into `.bootstrap/settings/{reponame}/targets` ```console mkdir -p ".bootstrap/settings/Finch" 2> /dev/null echo "Finch Demo" > .bootstrap/Finch/targets ``` Use `mulle-bootstrap -V` to get an extensive trace. ### It's not working as I expect now what ? Try to use some of the debug facilities. Each of these environment variables need to be set to **YES** to work. Environment Variable | Description --------------------------------------+------------------------------------- MULLE_BOOTSTRAP_VERBOSE | turn on a little more output. If you set it to VERBOSE instead of YES, it produces quite a bit more output. Set it to FULL for exhausting detail. Set it to 1848 for shell tracing. MULLE_BOOTSTRAP_TRACE | traces shell commands as they are executed MULLE_BOOTSTRAP_TRACE_SETTINGS | traces settings accesses It's easiest to use the three verbosity options though: ```console mulle-bootstrap -v mulle-bootstrap -V mulle-bootstrap -t ```