Mac Build

Not logged inOpenClonk Forum

Forum Home Help Search Watchlist Register Login

Topic Development / Developer's Corner / Mac Build

1 2

Post

By TLK

Date 2012-02-28 11:47

I was just wondering if someone could explain a few steps in regards of building Openclonk on a Mac. From memory the Mac support in the Clonk community isn't all that great; anyway i'm not in a hurry. The Steps in the Readme.txt aren't all that detailed so i'd be glad if someone could explain them in a different way or just link an understandable tutorial for the dependencies bit. At the moment i get an error from the CMake app:

[The CXX compiler identification is unknown
CMake Error at /Applications/CMake 2.8-7.app/Contents/share/cmake-2.8/Modules/CMakeFindBinUtils.cmake:71 (MESSAGE):
Could not find install_name_tool, please check your installation.
Call Stack (most recent call first):
/Applications/CMake 2.8-7.app/Contents/share/cmake-2.8/Modules/CMakeDetermineCXXCompiler.cmake:176 (INCLUDE)
CMakeLists.txt:27 (project)

CMake Error: Could not find cmake module file:/Users/tim-kuhrt/OpenClonkBuild/CMakeFiles/CMakeCXXCompiler.cmake
CMake Error: Could not find cmake module file:/Users/tim-kuhrt/OpenClonkBuild/CMakeFiles/CMakeCCompiler.cmake
Configuring incomplete, errors occurred!

I guess that i'm missing something (well obviously the mentioned files).

By Caesar

Date 2012-02-28 13:06

These files should come with your cmake-install. I don't know how cmake handles locating them, but that's where I'd investigate.

By richard [de]

Date 2012-02-28 16:46

I´m interested, too. It would be great, if there is a tutorial.

By PeterW

Date 2012-02-28 18:21

Are you sure that you have all requirements listed? I generally just install all dependencies from Homebrew, then do "cmake -G Xcode ." and build in Xcode.

It gets a good deal more complicated if you want universal binaries. Just working on packing the whole process into script form... Stupid SDL_mixer doesn't support cross-compiling properly :/

By richard [de]

Date 2012-02-28 20:02

I genereted the project in CMake. How it is described in the Readme-file.
Opened it with Xcode 4.2.1 - and now?
How do I built it?

By PeterW

Date 2012-02-28 20:15

Cmd+B?

By richard [de]

Date 2012-02-28 20:40

...well, than I did something wrong :-( it does not work.

By PeterW

Date 2012-02-28 20:41

What sort of error do you get?

By TLK

Date 2012-02-29 07:25

Well i had most of the requirements beforehand and updated them before i started. The only exemptions were the dependencies. I'm not certain if they are installed correctly but then again that does not seem to be the error does it?

By PeterW

Date 2012-02-29 13:11

Well, it is complaining that it can't find install_name_tool, which should be either part of OS X or XCode, as well as some pretty basic CMake components. Something's definitely missing.

By Mortimer [de]

Date 2012-03-27 14:15

I recently added some notes to README.mac.txt (http://hg.openclonk.org/openclonk/file/tip/README.mac.txt) and committed some mac-specific stuff. At least for me, it builds fine now.

By PeterW

Date 2012-02-28 20:40

Laundry list of stuff that has come up:

- Mac Os X has no librt, therefore clock_gettime is unavailable. Needs a proper check and fallback.

- XCode 4.2.1 only comes with SDKs back to 10.6. Building against that would mean limiting ourselves to Macs about one and a half year old and younger.

- Supporting all that C++0x gizmo requires linking against libc++ (which CMake doesn't detect) which again limits us to SDK 10.7. That would mean we can only support Macs about half a year old.

- And yes, GCC chokes on StdBuf without the C++0x gizmo.

Hm, have we ever considered whether it might be easier to just build StdBuf on top of std::auto_ptr? After all, that's pretty much where the approach is borrowed from.

By Newton

Date 2012-02-28 20:48

> Hm, have we ever considered whether it might be easier to just build StdBuf on top of std::auto_ptr? After all, that's pretty much where the approach is borrowed from.

Isilkor will cheer ^^

By PeterW

Date 2012-02-28 22:27

std::auto_ptr, not std::string. That might help with maintaining the code - the outside behavior on the other hand would remain unchanged. It's essentially the question whether we might be able to leave all the messy rvalue stuff to the standard library.

By Isilkor Date 2012-03-01 02:32

not really, std::auto_ptr is pretty horrible too

By Günther [de]

Date 2012-02-29 01:53

> Mac Os X has no librt, therefore clock_gettime is unavailable. Needs a proper check and fallback.

Gah, so much for trusting POSIX. See http://hg.openclonk.org/openclonk/rev/ef82a09b3d8f for an explanation and the old code which could be used as fallback, if you don't want to search for a monotonic clock on macosx.

> And yes, GCC chokes on StdBuf without the C++0x gizmo.

So you need to use a really old gcc from when the ALLOW_TEMP_TO_REF hack still worked? Alternatively, perhaps it is finally time to rewrite that stuff to be sane, i.e. not have copy and assignment operators that modify the source, but use functions for that.

By PeterW

Date 2012-02-29 10:44

> So you need to use a really old gcc from when the ALLOW_TEMP_TO_REF hack still worked?

Yes, that's what I meant. And yes, a "sane" way that still allows using buffers as return values would be nice indeed. I just don't see the alternative to auto_ptr-like behavior.

By Günther [de]

Date 2012-02-29 17:28

Well, return values should simply depend on the optimization that elides the copy constructor for them. The one that turns
Giant foo() { return Giant(constructedfromthesevalues); } void bar() { Giant g; g = foo(); }
into something like
void foo(Giant * to) { to->Giant(constructedfromthesevalues); } void bar() { Giant g; foo(&g); }
with the only observable difference to the programmer that the copy constructor wasn't called. One can even enforce that by declaring but not implementing the copy constructor, so that accidental copying is caught by the linker, because the optimization affects the ABI so is always active.

By PeterW

Date 2012-02-29 21:05

I don't feel it's a good idea to depend on optimizations. And do you really want to call, say, FormatString the way you described?

By Caesar

Date 2012-02-29 21:28

I don't like depending on optimizations either, but Return Value Optimization is really handy.

By Sven2

Date 2012-02-29 22:16

I think the idea is that you call FormatString the way you always did, but the optimizer will turn it into the code shown by Guenther.

By PeterW

Date 2012-02-29 23:55

Oh, I misread a bit. Disregard my second sentence.

By Günther [de]

Date 2012-03-01 00:37

I feel it is a very good idea to depend on optimizations for performance. Do I really need to argue for that?

(Though this is a special case of an optimization required by the calling convention, so even if we depended on it for correctness, we'd be save.)

> And do you really want to call, say, FormatString the way you described?

FormatString is already called the way I described. You can put some printfs in the StdStrBuf copy- and move-constructors and test for yourself.

By PeterW

Date 2012-03-01 13:05

Hm, yeah. The thing is that I'm not sure we can count that as a pure performance issue. That a copy is made is observable, after all - there *might* be references or pointers to the old buffer around. StdBuf is meant for predictably handling buffers (hence all the explicit Take/Copy/Ref stuff), so I don't like having to go "here we copy the buffer, invalidating all pointers... or possibly not".

I'd really prefer if we managed to solve it with auto_ptr instead.

By Günther [de]

Date 2012-03-01 19:57

Yeah, well, I'm willing to trade hypothetical errors on theoretical platforms for the real problem of our code containing non-obvious bugs where one stdbuf deletes the buffer while another still uses it. You may blame me for this if we ever have a bug of that nature.

By PeterW

Date 2012-03-01 20:32 Edited 2012-03-01 20:35

You mean, we are replacing the real problem that there might be references by the theoretical problem that there might be references? Isn't that labeling a bit arbitrary? ;)

Plus note we have code like this - are we sure that this wouldn't cause a copy of the part in question to be created? I mean, we can't rewrite it to

StdBuf IBufPart; IBufPart.Ref(IBuf.getPart(iPos, iIBufUsage - iPos));...

As that would segfault if your optimization doesn't run. I'm really uneasy with this. Do we really have to do this when we have basically exactly what you describe in StdCopyBuf already?

By Günther [de]

Date 2012-03-02 15:42 Edited 2012-03-02 15:45

We'd trade use-after-free for stale data. Even if it doesn't make the engine more correct, it should be less crashy.

> Plus note we have code like this - are we sure that this wouldn't cause a copy of the part in question to be created?

As sure as you can be of anything when C++ is involved. The compiler will only create one copy of getPart, and that one will use the caller-provided chunk of memory to create the returned object. Actually, that example looks even surer than the one I gave, because it elides the copy constructor, not the copy operator. (Or does it? All these little C++ details...)

But that code looks like it would work just as well with a copy, so I'm not going to worry about it.

> Do we really have to do this when we have basically exactly what you describe in StdCopyBuf already?

We at least need to rename the four classes so that the sane ones have the shorter names. I just thought that with the mac build breakage, we'd have enough momentum to do a bigger cleanup, and I wouldn't continue to procrastinate over the new names. Heh, these classes almost have both of the hard problems in computer science ;-) (naming and cache invalidation)

By PeterW

Date 2012-03-02 18:02

> But that code looks like it would work just as well with a copy, so I'm not going to worry about it.

Well, sorry, I *do* worry about it. That kind of code can run over buffers that are multiple megabytes large (say, downloads). This is the very reason I wrote the StdBuf code in the first place... I wanted an interface to work with networking buffers and parts of the networking buffers in uniform ways. Having a reliable mechanism for returning a reference to a buffer is an integral part of that.

> We at least need to rename the four classes so that the sane ones have the shorter names

Well, right now the simple and performance-safe ones have the simpler names. That made a lot of sense when refactoring - first you apply the suitable 1:1 transformation to StdBuf, then you possibly changed to StdCopyBuf to automate a few copying operations.

We might make a new "StdString" derive from "StdCopyStrBuf" or something, that would make sense.

By Günther [de]

Date 2012-03-02 20:52

Sorry, but between crashes like #706 and hypothetical performance problems we really should choose the latter. If you don't want your network code to change, I don't want to chase you away, but Std(Str)Buf is simply unsuitable for the rest of us. So how about renaming StdBuf to C4NetworkBuf, StdCopyBuf to C4ByteBuf, StdCopyStrBuf to C4StringBuf, and removing StdStrBuf?

By PeterW

Date 2012-03-03 20:51 Edited 2012-03-03 20:53

C4NetworkBuf sounds wrong as this is in no means specific to C4Network... If you want, you can go the route and make it "StdSimpleBuf" or "StdBufPtr" or similar to document that you're one step closer to the iron than you might expect. That would make sense to me.

Or we just rename StdCopyBuf into StdIdiotProofBuf. Ah, just kidding ;)

Edit: Trouble is, this still doesn't help the Mac build. Or am I missing something?

By Günther [de]

Date 2012-03-03 23:35

> C4NetworkBuf sounds wrong as this is in no means specific to C4Network...

The only other user that might conceivably use multi-megabyte copies is the stdcompiler, and I'll simply switch that one over to the sane buffer and do some performance profiles to confirm that it doesn't hurt.

Getting rid of StdBuf and StdStrBuf entirely would help the Mac build, which is why I brought that up in the first place. But I think the StdCompiler also needs this. Perhaps we could use const_casts for that.

By PeterW

Date 2012-03-03 23:50

The StdCompiler actually needs a string builder, which is a somewhat different concept. And naming questions are essentially documentation issues - and it doesn't make sense to document that one class is only used by one specific code piece unless it incorporates special logic for it.

> which is why I brought that up in the first place

And why I came back to it ;)

Right now this seems like a completely different issue to me. After all, we are just talking about a big renaming pass, followed by replacing StdStrBuf by StdCopyStrBuf and making sure it doesn't break anything? Neither really helps with the rvalue stuff on the "get-the-code-to-compile"-level.

By Günther [de]

Date 2012-03-04 17:54 Edited 2012-03-04 17:58

> and it doesn't make sense to document that one class is only used by one specific code piece unless it incorporates special logic for it.

The documentation aspect is that nobody should use that class. Because I don't feel like disproving your argument about multi-megabyte buffers with downloads, we have to grant you an exception for the network code. Hence C4NetworkBuf.

> After all, we are just talking about a big renaming pass, followed by replacing StdStrBuf by StdCopyStrBuf and making sure it doesn't break anything? Neither really helps with the rvalue stuff on the "get-the-code-to-compile"-level.

The only problem is passing temporary values to "foo &" parameters. StdCopy(Str)Buf takes "const foo &", so doesn't have the problem. And it isn't just a problem because ISO C++ doesn't allow this, it's also a problem because no coder expects this. And violating coder expectations leads to bugs.

StdCompiler may get away with simply const_casting the arguments. It's a complete surprise to any C++ writer anyway, and casual users only need to copy&paste some example code.

By Newton

Date 2012-03-04 13:26

If you guys rename the *Buf-classes, I'd suggest to rename to more self-describing (written-out) names and drop the "Std" (as any of the Std classes seem to be "Standard" to C4) too. E.g.:


StdStrBuf -> C4StringBuffer
StdCopyStrBuf -> C4CopyStringBuffer

By the way, do I understand it right that the only difference between StdStrBuf and StdCopyStrBuf is that the data StdCopyStrBuf points to is copied before modification and in StdStrBuf it is not? In that case StdStrBuf seems to be the more special class cause it differs from the normal behaviour I would expect from a string class.

(Also, if the StdCopyStrBuf is copied on modification, how is it a buffer?)

By PeterW

Date 2012-03-04 14:57

> the data StdCopyStrBuf points to is copied before modification

Not before modification, but at assignment (and initialization). So let's say you do

StdBuf blub = bla; blub = bla;

This will make two copies of "bla".

And yes, while we're at it, not using abbreviations might make sense as well.

By Caesar

Date 2012-03-04 16:44

>And yes, while we're at it, not using abbreviations might make sense as well.

In the current state, I don't think that makes sense. All three, Std, Str and Buf are pretty common abbreviations. At least, I never thought about what they could mean.

By PeterW

Date 2012-03-04 22:20

Yeah, it's a minor point at best - but if you think about it, having to remember whether it's "Buf" or "Buffer" is overhead information people shouldn't have to remember. And as abbreviations are often non-unique, the full name makes more sense as the default choice.

By Newton

Date 2012-03-05 20:53

This might draft of into the offtopic a bit, but why not use std::string? For the cases where the string data should not be copied on passing to other methods (which is why StdStrBuf exists, right?) it could be passed as a const reference.

By Caesar

Date 2012-03-05 20:58

You can't pass const references of function-local things as return values.

By Newton

Date 2012-03-06 12:07

I wasn't talking about return values.

By Isilkor Date 2012-03-07 20:59

that's what nrvo is for

By Mortimer [de]

Date 2012-03-01 16:36

More laundry list: the newest Xcode version from the App Store is self-contained and does not install to /Developer + other locations anymore. I don't think cmake can cope with that yet

By Caesar

Date 2012-03-01 17:32

Don't use the new XCode until there is a new cmake?

By PeterW

Date 2012-03-05 19:48

> Hm, have we ever considered whether it might be easier to just build StdBuf on top of std::auto_ptr?

Which doesn't really work, as the classic auto_ptr hack goes over an intermediate auto_ptr_ref class, which means that it doesn't have an implicit copy constructor. Hm :(

By Caesar

Date 2012-03-05 00:43

22:36:30 <!Zapper> I guess noone did the summon-produtive-peter-dance yet
22:43:55 <!JCaesar> Teach me.
22:44:06 <!JCaesar> It's more effective if we're doing it together, I guess .
22:47:21 <!Clonkonaut> \o/
22:47:23 <!Clonkonaut> o//
22:47:24 <!Clonkonaut> \\o
22:47:27 <!Clonkonaut> /o/
22:47:30 <!Clonkonaut> \o\
22:49:44 <!Isilkor> oh hey new archer tonight

By PeterW

Date 2012-03-05 03:36

If I might submit something in my defense - I've got an inch of sewage water in my rooms currently... ;)

I'll get back to the Mac build eventually, don't worry.

By Sven2

Date 2012-03-05 13:28

This + this should work! ;-)

By boni

Date 2012-03-05 13:32

Inb4 this

By richard [de]

Date 2012-04-20 20:36

Hallo,
I tried to build OC again, because I want to test the new features. But my XCode build faild again :(

Here is the code of the one error:

PhaseScriptExecution "CMake Rules" /Users/richard/desktop/Openclonk/openclonk.build/Debug/setup.build/Script-421E558FB4824CB1A726E52C.sh
cd /Users/richard/Desktop/Openclonk
/bin/sh -c /Users/richard/desktop/Openclonk/openclonk.build/Debug/setup.build/Script-421E558FB4824CB1A726E52C.sh

MAKENSIS-NOTFOUND -NOCD -DSRCDIR=/Users/richard/desktop/Openclonk "-DPROGRAMFILES=\$PROGRAMFILES" "-DPRODUCT_NAME=OpenClonk Beyond the Rocks" "-DPRODUCT_COMPANY=OpenClonk Project" "-DCLONK=\\Users\\richard\\desktop\\Openclonk\\Debug\\clonk.app\\Contents\\MacOS\\clonk" "-DC4GROUP=\\Users\\richard\\desktop\\Openclonk\\Debug\\c4group" /Users/richard/desktop/Openclonk/tools/install/oc.nsi "-XOutFile setup_openclonk.exe"
/bin/sh: MAKENSIS-NOTFOUND: command not found
make: *** [/Users/richard/desktop/Openclonk/setup_openclonk.exe] Error 127
Command /bin/sh failed with exit code 2

By Isilkor Date 2012-04-20 22:06

I have no idea why the Mac build tries to create a Windows installer, but it's probably not a problem (it looks like a proper clonk.app was built).

Topic Development / Developer's Corner / Mac Build

1 2

Post