+- Forums (https://www.vdrift.net/Forum)
+-- Forum: Project (https://www.vdrift.net/Forum/forumdisplay.php?fid=4)
+--- Forum: Development (https://www.vdrift.net/Forum/forumdisplay.php?fid=9)
+--- Thread: Universal binary support in scons on mac (/showthread.php?tid=730)
Pages:
1
2
Universal binary support in scons on mac - bugsyv - 07-16-2007
Just committed. It's off by default ( as it's just extra build time for developers ), but to enable it, specify the option "universal=all".
Which brings up a new point. Right now the universal build supports i386 and ppc. However, the 10.4u SDK supports 4-architecture binaries ( ppc_64, i386_64, ppc, i386). Has VDrift been tested in 64-bit architectures? Adding the two new archs should be simple... aside from getting new dependencies.
As always, if I have wreaked havoc on other systems, let me know.
- thelusiv - 07-16-2007
VDrift has been tested and is definitely working on AMD64. I'm not sure if that means that it will work on the other 64-bit architectures or not, but my guess is that it should be fine.
Thanks for your work on this btw.
Re: Universal binary support in scons on mac - abs1nth - 07-16-2007
bugsyv Wrote:It's off by default ( as it's just extra build time for developers ), but to enable it, specify the option "universal=all".great news!
does building with scons have the distinction between development and release/deployment builds? if so we could mimic what XCode does, namely building just for $NATIVE_ARCH when in development build and make an universal binary when doing an deployment/release build.
bugsyv Wrote:However, the 10.4u SDK supports 4-architecture binaries ( ppc_64, i386_64, ppc, i386)..
it really doesn't (support 4 architectures). 64-bit applications are only supported for non-gui applications (command line). that is why they are making that big fuss over 64 bit support in 10.5.
Re: Universal binary support in scons on mac - alex25 - 07-16-2007
bugsyv Wrote:As always, if I have wreaked havoc on other systems, let me know.
you changed the data installation location to $prefix/share/games/vdrift/data (from $prefix/share/games/vdrift/). can we go back to the way it used to be?
--alex--
- thelusiv - 07-17-2007
I'd say that the data directory should be separate from the main VDrift dir, that's how we do it on other platforms. Also this makes it easier to mess around with the data without worrying about touching the other files.
- alex25 - 07-17-2007
thelusiv Wrote:I'd say that the data directory should be separate from the main VDrift dir, that's how we do it on other platforms. Also this makes it easier to mess around with the data without worrying about touching the other files.
not really sure if this is in response to my posting. i was pointing out that before the latest changes to SConstruct the data was installed in /usr/local/share/games/vdrift but now it goes in /usr/local/share/games/vdrift/data which is ugly (only data goes in /usr/local/share/games/vdrift there is no need for the extra "data" directory). and apparently the executable now goes in /usr/local/share/games/vdrift/bin/vdrift (instead of /usr/local/bin/vdrift). for now i just changed:
Code:
default_datadir = "share/games/vdrift"
default_bindir = "bin"--alex--
- bugsyv - 07-17-2007
Sure I can make that change. My intention was to keep things as they were on other systems, and if I didn't it's only because I got confused about what was being done in the original.
Should be fixed shortly if someone hasn't gotten to it before me.
Re: Universal binary support in scons on mac - bugsyv - 07-17-2007
abs1nth Wrote:it really doesn't (support 4 architectures). 64-bit applications are only supported for non-gui applications (command line). that is why they are making that big fuss over 64 bit support in 10.5.
OK. I'm not completely up to speed with all that. I guess since we do use a little cocoa, then we qualify as a gui app then. I suppose we can wait for the new system before adding 64-bit support. Not that it will really matter to me personally
Anyways, yes scons can distinguish between release and debug (release=1) however, I personally wouldn't want to switch universal support on this because I can't really use debug... I get something like 8FPS there.
- bugsyv - 07-17-2007
bugsyv Wrote:Should be fixed shortly if someone hasn't gotten to it before me.
Actually, reviewing the file before my changes...
default_datadir and default_bindir have the same values that were applied directly to the option.Add(PathOption()) for the options in question before...
So I am not quite sure how stuff was getting installed to the locations indicated.
Since, I don't work on this platform, I will defer the decision to change the default values to someone who does.
alex25, if you don't like the default values, you can always change them when running scons:
Code:
$ scons datadir=share/games/vdrift bindir=binYou only have to do this once because the settings are persisted and automatically applied during subsequent builds.
- alex25 - 07-17-2007
bugsyv Wrote:alex25, if you don't like the default values, you can always change them when running scons:
i never really liked scons (more used to makefiles) so i prefer editing the files themselves. actually, this is exactly one of the reasons i hate scons: running it with extra options shouldn't really be persistent across options. i am sure at some point i'll forget i ran scons with the extra options and then i'll try to figure out, in vain, why it is installing things where it does. to each its own, i guess.
--alex--
- bugsyv - 07-17-2007
alex25 Wrote:actually, this is exactly one of the reasons i hate scons: running it with extra options shouldn't really be persistent across options. i am sure at some point i'll forget i ran scons with the extra options and then i'll try to figure out, in vain, why it is installing things where it does. to each its own, i guess.Persisting the options is an optional feature of scons and was put in there deliberately by this project. Though I do see what you mean... perhaps there should be an option to persist the options
run it once like soCode:
$scons bindir=bin save=1And scons doesn't really replace makefiles... it replaces autoconf and the resulting makefiles. But there seems to be 101 different build systems out there so none is perfect ( otherwise everyone would be using it )
- thelusiv - 07-17-2007
alex25, we've been installing VDrift to /usr/share/games/vdrift/bin and data to /usr/share/games/vdrift/data for a long time now, at least two versions back. The reason is that BinReloc can find the data easily this way. Why depend on BinReloc? In the case of autopackage (our main package format) the user has the option to install system wide by giving the root pass or in their home directory. The game should be able to find its data relative to the binary's directory no matter where it is.
Also it makes it simple to move or remove the game - only one directory needs to be removed. As bugsyv mentioned, you can always specify different directories when running scons, if you don't need these features.
Also, we have had an option to turn off saving of scons options for a while too. This is the cache option. It is primarily used for packaging, for instance when we make autopackages, there are a bunch of options passed to scons but we don't want them to be remembered since the developer has his own set of options saved and wants to use those most of the time. So just run
Code:
scons cache=0If you're a make fan, you can still use that. Just write a Makefile with something like this in it:
Code:
all:
scons option=0 otheroption=1 stuff=blahFor more info on the options scons allows you to set for building VDrift, you can run
Code:
scons -h- alex25 - 07-17-2007
thelusiv Wrote:I'd really appreciate it if you tell me if the things there make sense. Maybe the help could be better.
personally i put all my executables in one directory. i hate having my path include a million directories. this is how unix traditionally behaved (including linux), but then the windows people showed up. in the unix context it makes sense to have the data go in /usr/local/share/games/vdrift (sans the data part). i would also skip the games part of the directory path but it's already there and i can't be bothered to change it for now.
if you want to install everything in one directory, that's your prerogative. as much as i hate scons, i've learned enough to modify it locally (and make myself happy). sorry to bother you guys.
--alex--
- thelusiv - 07-17-2007
The reasons for installing in this way really has nothing to do with Windows, or my personal prerogative. As I said before there are technical reasons, mostly to do with BinReloc. I understand the Unix tradition of executables all being in one directory. If you want VDrift to be in your PATH you need not modify the environment variable. Simply add a symbolic link for $prefix/share/games/vdrift/bin/vdrift in $prefix/bin/. Autopackage does this for you, I started making SCons do this to but my first attempt didn't work right, and I haven't followed up on it.
The way I've set up SCons, I've aimed at it being as flexible as possible - that is, I have tried to add options for everything we need to do, rather than constantly make changes to the SCons* files. If there's an option in the build you want, let me know, I'll do my best to add it. Otherwise I encourage you to learn to use the system that's there. Editing the SCons* files gets you basically the same thing as persistently saved options, so I don't really see the difference.
I know that SCons won't satisfy everyone in every way. I certainly don't think it's perfect. No build system can possibly be - neither autotools, SCons, jam, code::blocks, or plain old make. However it does what we want and automates a lot of things for us. We are pretty close to having one build system that works almost identically on all platforms and that is a pretty big accomplishment, I think. I've done small to medium software projects before with lots of different build setups, most commonly plain Makefile, and I'll be the first to say that would not be easily maintained for a big project like VDrift. It would also be a big step down from SCons in terms of functionality (how about getting make to check for libraries, or set the build version to the date, or generate the definitions.h file...on every OS?)...
I'm happy to hear about alternatives. I'm the last person who would want to stick with a technically inferior system when there's something better available. If you know of a better build system please tell us about it. Whatever it may be, it will have to be closely evaluated before we'll consider going through the trouble to change things.
So you can hate the system if you want, but unless you can come up with something better, I'd suggest try to use the system as it's intended. You might find it's not so bad. If you find problems with it please bring them up for discussion and we'll do the best we can to fix them. I personally have done a lot to make things easier for developers because I am one...so tell me how I can make it better for you. Thanks
Re: Universal binary support in scons on mac - abs1nth - 07-18-2007
bugsyv Wrote:I guess since we do use a little cocoa, then we qualify as a gui app the.
nah, we are a GUI app because we draw something on screen after all, using plain opengl minus the cocoa stuff wouldn't change the situation.