Build environment and deployment on the Mac

[historic_bruno]

Here's my report for the compilation.

Thanks! Your steps more or less agreed with svenstaro's patch here, but that would break pre-1.44 Boost, so I made a new patch for compatibility with v2 and v3 depending on the Boost version available. Tested on OS X Lion w/ Boost 1.49 and 1.50. Hopefully it works for you too If I get time, I'll try compiling Boost 1.43 and confirming that works, then commit the patch for A11.

[wraitii]

Yep, those changes work for me.

[Echelon9]

Sorry for not reading right through, but does this mean we are approaching an *easy*, repeatable OS X build environment within Xcode?

i.e. without having to go through the hoops of an external package maintainer like macports?

[historic_bruno]

Sorry for not reading right through, but does this mean we are approaching an *easy*, repeatable OS X build environment within Xcode?

i.e. without having to go through the hoops of an external package maintainer like macports?

Well I think this is pretty easy: https://github.com/h.../tree/osx-build No MacPorts/Homebrew/etc required, just run the libraries/osx/build-osx-libs.sh script. You do need cmake to build NVTT - that's the only dependency not handled by the script. Testing welcome, if you want to try Git. But I won't be able to update that branch until I'm back on my main computer.

[MishFTW]

I'll pass

The one punishment for not compiling myself... I have to wait.

[juniorbl]

Hello everyone,

I'm trying to compile the project using Xcode 4.5 on mountain lion using the historicbruno's version from this repository on github https://github.com/h.../tree/osx-build and the script to build the dependencies in the same repository (related to this ticket http://trac.wildfire...com/ticket/1112), I just had to change the path to SDK MacOSX10.7 in the file build-osx-bundle.sh and I get the following error. The script generates a project file for Xcode3, that could be the problem but I'm not sure. I googled the error and tried different solutions like changing the "Other Linker Flags" but it caused even more errors, I'm not familiar with Xcode.

Any ideas? Thank you.

Libtool ../../../binaries/system/libmocks_real_dbg.a normal x86_64
		cd /Users/myUser/src/0ad-mac/0ad/build/workspaces/xcode3
		/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool -static -arch_only x86_64 -L/Users/myUser/src/0ad-mac/0ad/build/workspaces/xcode3/../../../binaries/system -L../../../binaries/system -filelist /Users/myUser/src/0ad-mac/0ad/build/workspaces/xcode3/obj/mocks_real_Debug/mocks_real.build/Objects-normal/x86_64/mocks_real_dbg.LinkFileList -lboost_filesystem-mt -lboost_system-mt -Wl,-syslibroot,/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk -mmacosx-version-min=10.6 -o /Users/myUser/src/0ad-mac/0ad/build/workspaces/xcode3/../../../binaries/system/libmocks_real_dbg.a
	/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: unknown option character `W' in: -Wl,-syslibroot,/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk
	Usage: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool -static [-] file [...] [-filelist listfile[,dirname]] [-arch_only arch] [-sacLT]
	Usage: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool -dynamic [-] file [...] [-filelist listfile[,dirname]] [-arch_only arch] [-o output] [-install_name name] [-compatibility_version #] [-current_version #] [-seg1addr 0x#] [-segs_read_only_addr 0x#] [-segs_read_write_addr 0x#] [-seg_addr_table <filename>] [-seg_addr_table_filename <file_system_path>] [-all_load] [-noall_load]
	Command /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool failed with exit code 1

Edited January 10, 2013 by juniorbl

[historic_bruno]

That's weird, it shouldn't be running libtool with the linker options. Honestly I don't even try building the game with Xcode, it's not worth it to me, though it's still useful for code editing. I use the "gcc" workspace instead, after installing the command line tools for Xcode. It should be no more difficult than running the make command, possibly you'll need to do "export CC=llvm-gcc CXX=llvm-g++" first.

[juniorbl]

That's weird, it shouldn't be running libtool with the linker options. Honestly I don't even try building the game with Xcode, it's not worth it to me, though it's still useful for code editing. I use the "gcc" workspace instead, after installing the command line tools for Xcode. It should be no more difficult than running the make command, possibly you'll need to do "export CC=llvm-gcc CXX=llvm-g++" first.

Right but do you use something to debug? I wanted to run inside Xcode because would be easier to debug and study the code. I tried codeblocks but it crashes all the time.

Regards.

[historic_bruno]

gdb Though I do most of my development on Windows, so it's rare that I need to debug on OS X specifically. Looks like the latest Premake beta supports Xcode 4, I'll look into whether we can easily integrate it.

[historic_bruno]

Oops, I was wrong, it should be using libtool (which can pass flags through to ld), the problem is that for some reason the Xcode project doesn't have the paths to the libs matching my osx-build branch.

Tested the Premake Xcode4 support, it seems to fix the various upgrade warnings and adds a single workspace, though it still looks like a pain to switch between release and debug builds. I don't see any problem with committing it to SVN. It's unrelated to this particular problem though.

[historic_bruno]

Ok, I've found the problem, it actually exists in SVN as well and has for some time. I was wondering why on some projects, Boost was the only library being linked, and also the cause of your error. During the build process, we don't link against anything for static libs, as that causes problems in Xcode, which this comment in extern_libs4.lua explains:

-- On osx using xcode, if this linking would be defined in the static libraries, it would fail to

-- link if only dylibs are available. If both *.a and *.dylib are available, it would link statically.

-- I couldn't find any problems with that approach.

This worked fine in the past, it simply ignores the link settings for projects that are static libs (they get pulled in by dynamic libs and applications instead). But we modified Boost's link settings once, and accidentally put them in the wrong spot, the result is the above logic doesn't catch that, and Boost is linked even for static libs. This is the cause of your error, which is Xcode specific. I will commit a fix to SVN and then push it to my Github repo as well.

Thanks for testing!

[juniorbl]

I'm running and debugging it in Xcode

I didn't get you fix yet and I'm not entirely sure if the things I did are right or if my system has problems but I hope it helps something:

When I loaded the project in Xcode for the first time I had the libtool error I reported yesterday. I googled a little bit and removed

-Wl,-syslibroot,/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk -mmacosx-version-min=10.6

from each project in Build Settings > Other Linker Flags.

I tried again and this time it was complaining about this:

Linking pyrogenesis
Undefined symbols for architecture x86_64:
  "_TIFFClose", referenced from:
	  nv::ImageIO::saveFloatTIFF(char const*, nv::FloatImage const*, unsigned int, unsigned int)in libnvimage.a(ImageIO.cpp.o)
	  nv::ImageIO::loadFloatTIFF(char const*, nv::Stream&)in libnvimage.a(ImageIO.cpp.o)
  "_TIFFDefaultStripSize", referenced from:
	  nv::ImageIO::saveFloatTIFF(char const*, nv::FloatImage const*, unsigned int, unsigned int)in libnvimage.a(ImageIO.cpp.o)
  "_TIFFGetField", referenced from:
	  nv::ImageIO::loadFloatTIFF(char const*, nv::Stream&)in libnvimage.a(ImageIO.cpp.o)
  "_TIFFOpen", referenced from:
	  nv::ImageIO::saveFloatTIFF(char const*, nv::FloatImage const*, unsigned int, unsigned int)in libnvimage.a(ImageIO.cpp.o)
	  nv::ImageIO::loadFloatTIFF(char const*, nv::Stream&)in libnvimage.a(ImageIO.cpp.o)
  "_TIFFReadScanline", referenced from:
	  nv::ImageIO::loadFloatTIFF(char const*, nv::Stream&)in libnvimage.a(ImageIO.cpp.o)
  "_TIFFScanlineSize", referenced from:
	  nv::ImageIO::loadFloatTIFF(char const*, nv::Stream&)in libnvimage.a(ImageIO.cpp.o)
  "_TIFFSetField", referenced from:
	  nv::ImageIO::saveFloatTIFF(char const*, nv::FloatImage const*, unsigned int, unsigned int)in libnvimage.a(ImageIO.cpp.o)
  "_TIFFWriteScanline", referenced from:
	  nv::ImageIO::saveFloatTIFF(char const*, nv::FloatImage const*, unsigned int, unsigned int)in libnvimage.a(ImageIO.cpp.o)
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status
make[1]: *** [../../../binaries/system/pyrogenesis] Error 1
make: *** [pyrogenesis] Error 2

You said you don't use Xcode so I tried gcc and had the same error. Google to the rescue again and I copied "libnvimage.dylib" from another 0ad repository I have to libraries/source/nvtt/lib. Here I could compile the game.

I tried to run it in Xcode or in the console and I saw this one:

dyld: Library not loaded: @executable_path/libnvimage.dylib
  Referenced from: /Users/myUser/src/0ad-mac/0ad/binaries/system/./pyrogenesis
  Reason: image not found
Trace/BPT trap: 5

I copied "libnvimage.dylib" to binaries/system/ and it complained two more times about "libnvcore.dylib" and "libnvmath.dylib" saying they were referenced from "libnvimage.dylib". I copied those libraries again and voilà.

Now I can debug and study how everything works. Thanks for the help.

Edited January 12, 2013 by juniorbl

[historic_bruno]

For what it's worth, I tested osx-build with Xcode 4.3 on Lion with r13065 and r13066, it built perfectly on the first attempt I've upgraded to Xcode 4.5 and as soon as our Github repo is updated, I'll test again with that.

Out of curiousity did you run ./build-osx-libs.sh in /libraries/osx directly? It shouldn't use libnv*.dylib at all, since it should be linking NVTT statically.

[historic_bruno]

The mentioned updates are now available on the osx-build branch. I've confirmed that the new xcode4 workspace builds with Xcode 4.5.2 and the command line tools installed on Lion. (This version of Xcode doesn't include the 10.6 SDK, which may or may not pose a problem in practice, but it doesn't seem 100% required for building a 10.6 compatible app)

I'd be interested to see how it works for you and anyone else on OS X, as it's getting to the point where I'm considering merging it into SVN.

[Echelon9]

Great to hear!

[juniorbl]

For what it's worth, I tested osx-build with Xcode 4.3 on Lion with r13065 and r13066, it built perfectly on the first attempt I've upgraded to Xcode 4.5 and as soon as our Github repo is updated, I'll test again with that.

Out of curiousity did you run ./build-osx-libs.sh in /libraries/osx directly? It shouldn't use libnv*.dylib at all, since it should be linking NVTT statically.

Yes, I ran it in /libraries/osx. After that I read build-osx-bundle.sh more carefully and saw that it also runs build-osx-libs.sh, so I ended up running it twice.

The mentioned updates are now available on the osx-build branch. I've confirmed that the new xcode4 workspace builds with Xcode 4.5.2 and the command line tools installed on Lion. (This version of Xcode doesn't include the 10.6 SDK, which may or may not pose a problem in practice, but it doesn't seem 100% required for building a 10.6 compatible app)

I'd be interested to see how it works for you and anyone else on OS X, as it's getting to the point where I'm considering merging it into SVN.

I just cloned the osx-build branch, changed the MacOSX sdk path and ran build-osx-bundle.sh and I got this error:

...
Linking AtlasUI
Linking test
ld: warning: direct access in boost::signals::detail::slot_call_iterator<boost::signals::detail::call_bound0<void>::caller<boost::function<void ()()> >, boost::signals::detail::named_slot_map_iterator>::dereference() constto global weak symbol vtable for boost::bad_function_callmeans the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
ld: warning: direct access in boost::signals::detail::slot_call_iterator<boost::signals::detail::call_bound1<void>::caller<AtObj const&, boost::function<void ()(AtObj const&)> >, boost::signals::detail::named_slot_map_iterator>::dereference() constto global weak symbol vtable for boost::bad_function_callmeans the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
ld: warning: direct access in boost::signals::detail::slot_call_iterator<boost::signals::detail::call_bound1<void>::caller<AtlasMessage::sEnvironmentSettings const&, boost::function<void ()(AtlasMessage::sEnvironmentSettings const&)> >, boost::signals::detail::named_slot_map_iterator>::dereference() constto global weak symbol vtable for boost::bad_function_callmeans the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
ld: warning: direct access in boost::signals::detail::slot_call_iterator<boost::signals::detail::call_bound1<void>::caller<ObjectSettings const&, boost::function<void ()(ObjectSettings const&)> >, boost::signals::detail::named_slot_map_iterator>::dereference() constto global weak symbol vtable for boost::bad_function_callmeans the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
ld: warning: direct access in boost::signals::detail::slot_call_iterator<boost::signals::detail::call_bound1<void>::caller<wxString const&, boost::function<void ()(wxString const&)> >, boost::signals::detail::named_slot_map_iterator>::dereference() constto global weak symbol vtable for boost::bad_function_callmeans the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
ld: warning: direct access in boost::signals::detail::slot_call_iterator<boost::signals::detail::call_bound1<void>::caller<std::vector<unsigned int, std::allocator<unsigned int> > const&, boost::function<void ()(std::vector<unsigned int, std::allocator<unsigned int> > const&)> >, boost::signals::detail::named_slot_map_iterator>::dereference() constto global weak symbol vtable for boost::bad_function_callmeans the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
ld: warning: direct access in boost::signals::detail::slot_call_iterator<boost::signals::detail::call_bound1<void>::caller<ITool*, boost::function<void ()(ITool*)> >, boost::signals::detail::named_slot_map_iterator>::dereference() constto global weak symbol vtable for boost::bad_function_callmeans the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
ERROR: Game build failed!

I opened the Xcode (xcode4) project and got the same problem:

Libtool ../../../binaries/system/libmocks_real_dbg.a normal x86_64
	cd /Users/myUser/src/0ad-mac2/0ad/build/workspaces/xcode4
	/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool -static -arch_only x86_64 -L/Users/myUser/src/0ad-mac2/0ad/build/workspaces/xcode4/../../../binaries/system -L../../../binaries/system -filelist /Users/myUser/Library/Developer/Xcode/DerivedData/pyrogenesis-budvwkvggudeghhiiqhgqknpjish/Build/Intermediates/mocks_real.build/Objects-normal/x86_64/mocks_real_dbg.LinkFileList -Wl,-syslibroot,/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk -mmacosx-version-min=10.6 -o /Users/myUser/src/0ad-mac2/0ad/build/workspaces/xcode4/../../../binaries/system/libmocks_real_dbg.a
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool: unknown option character `W' in: -Wl,-syslibroot,/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk
Usage: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool -static [-] file [...] [-filelist listfile[,dirname]] [-arch_only arch] [-sacLT]
Usage: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool -dynamic [-] file [...] [-filelist listfile[,dirname]] [-arch_only arch] [-o output] [-install_name name] [-compatibility_version #] [-current_version #] [-seg1addr 0x#] [-segs_read_only_addr 0x#] [-segs_read_write_addr 0x#] [-seg_addr_table <filename>] [-seg_addr_table_filename <file_system_path>] [-all_load] [-noall_load]
Command /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/libtool failed with exit code 1

It thought it could be something related to the version 7 of the MacOSX sdk but I tried the version 8 and got the same errors.

Edited January 16, 2013 by juniorbl

[historic_bruno]

Yes, I ran it in /libraries/osx. After that I read build-osx-bundle.sh more carefully and saw that it also runs build-osx-libs.sh, so I ended up running it twice.

To clarify, build-osx-bundle is an automated process, there's no need to open anything in Xcode, though of course you do need Xcode installed for its SDKs.

I think there's some confusion about the procedure for using that branch. There are two choices:

1. build a loose binary with Xcode/command line, in this case you want to run build-osx-libs.sh first, followed by update-workspaces.sh, then you're ready to build with gcc/xcode4

2. build a bundle using build-osx-bundle.sh which doesn't involve running Xcode or anything else (assuming it succeeds)

They are meant to be mutually exclusive. It's not really desirable to mix the steps, though if done correctly I see no harm in running build-osx-bundle.sh first, which builds the libraries against a specific SDK and deployment target rather than the system default, and then reusing that to do another non-bundle build. In fact, I often do this simply because it takes so long to build all the libs again.

I just cloned the osx-build branch, changed the MacOSX sdk path and ran build-osx-bundle.sh and I got this error:

Those are only warnings, if you look at the full build log, you should find the error that caused it to fail.

I opened the Xcode (xcode4) project and got the same problem:

It might be better if you run update-workspaces.sh after using build-osx-bundle.sh. When you do, don't use any SDK or bundle options, as those are only for a command line build (Xcode probably has its own special ways of handling SDKs, deployment targets, and bundles, in the project files).

[juniorbl]

To clarify, build-osx-bundle is an automated process, there's no need to open anything in Xcode, though of course you do need Xcode installed for its SDKs.

I think there's some confusion about the procedure for using that branch. There are two choices:

1. build a loose binary with Xcode/command line, in this case you want to run build-osx-libs.sh first, followed by update-workspaces.sh, then you're ready to build with gcc/xcode4

2. build a bundle using build-osx-bundle.sh which doesn't involve running Xcode or anything else (assuming it succeeds)

They are meant to be mutually exclusive. It's not really desirable to mix the steps, though if done correctly I see no harm in running build-osx-bundle.sh first, which builds the libraries against a specific SDK and deployment target rather than the system default, and then reusing that to do another non-bundle build. In fact, I often do this simply because it takes so long to build all the libs again.

Those are only warnings, if you look at the full build log, you should find the error that caused it to fail.

It might be better if you run update-workspaces.sh after using build-osx-bundle.sh. When you do, don't use any SDK or bundle options, as those are only for a command line build (Xcode probably has its own special ways of handling SDKs, deployment targets, and bundles, in the project files).

Ops, I wasn't running update-workspaces.sh. Now, using xcode or gcc, the only problem is the libnvimage.a I reported above. I'll try to find if I'm doing something wrong, maybe something related to build-osx-libs.sh like you said.

Edited January 16, 2013 by juniorbl

[wraitii]

FYI: using the new xcode 4 projects, SVN compiled nicely without any issue on my repo. The only problem (already there before) is that you have to manually change all the "build schemes" to release if you don't want to play in debug mode.

[historic_bruno]

Yeah, that's because Premake is not properly using schemes There should be two schemes: release and debug (matching the Premake concept of configurations), but instead each project gets turned into a scheme by Xcode and debug is the default build configuration for some reason. I don't know if we can have separate projects combined under two schemes, in a single workspace, anyone with Xcode 4 experience know about that?

[historic_bruno]

Here's a solution I've found as a workaround, it involves manually creating the proper schemes:

• Open the Xcode 4 workspace. In the top left corner of the Xcode window, you'll see a Scheme selector. Click that and choose "Manage Schemes..." All the schemes that are listed are autocreated by Xcode and most of them aren't useful, they can be deleted or hidden (by unchecking "Show").
  
• Create a new scheme with the (+) button, name it something like "pyrogenesis (release)" and set the target to "pyrogenesis". Double click the new scheme to open its settings. Select Build in the left column. Add (+) two new targets: AtlasUI and Collada. In the left column, choose Run and set the build configuration to "Release". Do the same for Test and Analyze.
  
• Now copy that scheme using the Duplicate Scheme button, naming it something like "pyrogenesis (debug)". For each of Run, Test, Profile, Analyze and Archive in the left column, set the build configuration to "Debug".
  
• There should now be two schemes pyrogenesis (release) and pyrogenesis (debug) that have the correct build configuration. You can also create another scheme for the test target, one for Atlas, etc.
  

The schemes only specify build/test/profile/etc. configurations, so you can delete them or create as many as you want, multiple users can have their own different schemes or they can be shared. You could create a scheme that runs Atlas, or passes autostart options to test a given map, etc.

It should be possible to generate release and debug schemes with Premake, they are XML files that get stored in pyrogenesis.xcworkspace/xcshareddata/xcschemes/*.xcscheme

[historic_bruno]

osx-build branch has been merged into SVN! http://trac.wildfire...changeset/13148

(CMake is still a required dependency to build NVTT, get the OS X package here)

If you're on OS X and want to test it, my advice is:

• delete all *.dylib and *.a in binaries/system
  
• run ./clean-workspaces.sh in build/workspaces
  
• run ./build-osx-libs.sh in libraries/osx -- it will download and build a lot of libraries from source
  
• run ./update-workspaces.sh in build/workspaces
  
• do a clean build ("make clean && make" in gcc workspace, if using gcc, or Product > Clean in Xcode)
  

(I only include the cleaning steps to be safe since the build system has changed, those aren't typically needed)

That will build a loose binary. The process if you want to build a bundle takes longer but is simpler:

• delete all *.dylib and *.a in binaries/system
  
• run ./build-osx-bundle.sh in build/workspaces -- this will take a while... but it does everything else
  

[historic_bruno]

It should be possible to generate release and debug schemes with Premake, they are XML files that get stored in pyrogenesis.xcworkspace/xcshareddata/xcschemes/*.xcscheme

This Premake fork seems to have some support for schemes: https://bitbucket.org/liamdevine/premake-dev-xcode4/src/65e4fb2ace8aebce03368bbe8986e48a8043198c/src/actions/xcode?at=default

[Echelon9]

osx-build branch has been merged into SVN! http://trac.wildfire...changeset/13148

If you're on OS X and want to test it, my advice is:

• delete all *.dylib and *.a in binaries/system
  
• run ./clean-workspaces.sh in build/workspaces
  
• run ./build-osx-libs.sh in libraries/osx -- it will download and build a lot of libraries from source
  
• run ./update-workspaces.sh in build/workspaces
  
• do a clean build ("make clean && make" in gcc workspace, if using gcc, or Product > Clean in Xcode)
  

(I only include the cleaning steps to be safe since the build system has changed, those aren't typically needed)

That will build a loose binary. The process if you want to build a bundle takes longer but is simpler:

• delete all *.dylib and *.a in binaries/system
  
• run ./build-osx-bundle.sh in build/workspaces -- this will take a while... but it does everything else
  

Fantastic! So this is the beneficiary of not utilising MacPorts and building the libs from source?

Edit: Hrmm, I have Xcode 4.6 plus the Command Line Tools, and when following the first set of steps above I get an error building NVTT as it relies on cmake, which isn't included by default. So it's not fully without dependencies.

Building NVTT...
~/Documents/Coding/0ad/trunk/libraries/source/nvtt ~/Documents/Coding/0ad/trunk/libraries/osx
~/Documents/Coding/0ad/trunk/libraries/source/nvtt/src ~/Documents/Coding/0ad/trunk/libraries/source/nvtt ~/Documents/Coding/0ad/trunk/libraries/osx
~/Documents/Coding/0ad/trunk/libraries/source/nvtt/src/build ~/Documents/Coding/0ad/trunk/libraries/source/nvtt/src ~/Documents/Coding/0ad/trunk/libraries/source/nvtt ~/Documents/Coding/0ad/trunk/libraries/osx
./build-osx-libs.sh: line 430: cmake: command not found
ERROR: NVTT build failed

Edited February 9, 2013 by Echelon9

[leper]

Yes, the new build instructions for OS X just require you to build the libraries once (excluding upgrades of those) and helps us get rid of the dependency on MacPorts or Homebrew. It just requires OS X users to install xcode (or the developer tools including clang) which are already needed to build 0 A.D. .

It also makes creating bundles and building from source easier.