Switching to premake build configuration

[NaN]

To reduce the maintenance burden, we had Sconscript, codeblocks, xcode files to be kept in sync, we (NaN+antoniovazquez) have moved the codebase to premake build config tool to allow us to support a variety of build systems: http://industriousone.com/what-premake

Additionally the mac and win dependencies have been moved out of master into separate repos.

If you are experiencing any problems using premake report here.

[alex25]

Code:

Linking vdrift
/usr/local/lib/libBulletDynamics.a(btSequentialImpulseConstraintSolver.o): In function `btSequentialImpulseConstraintSolver::solveGroup(btCollisionObject**, int, btPersistentManifold**, int, btTypedConstraint**, int, btContactSolverInfo const&, btIDebugDraw*, btStackAlloc*, btDispatcher*)':
btSequentialImpulseConstraintSolver.cpp:(.text+0x4a): undefined reference to `CProfileManager::Start_Profile(char const*)'
btSequentialImpulseConstraintSolver.cpp:(.text+0x106): undefined reference to `CProfileManager::Stop_Profile()'
btSequentialImpulseConstraintSolver.cpp:(.text+0x134): undefined reference to `CProfileManager::Stop_Profile()'
/usr/local/lib/libBulletDynamics.a(btSequentialImpulseConstraintSolver.o): In function `btSequentialImpulseConstraintSolver::solveGroupCacheFriendlyIterations(btCollisionObject**, int, btPersistentManifold**, int, btTypedConstraint**, int, btContactSolverInfo const&, btIDebugDraw*, btStackAlloc*)':
btSequentialImpulseConstraintSolver.cpp:(.text+0x295f): undefined reference to `CProfileManager::Start_Profile(char const*)'
btSequentialImpulseConstraintSolver.cpp:(.text+0x29e8): undefined reference to `CProfileManager::Stop_Profile()'
btSequentialImpulseConstraintSolver.cpp:(.text+0x2a02): undefined reference to `CProfileManager::Stop_Profile()'
/usr/local/lib/libBulletDynamics.a(btSequentialImpulseConstraintSolver.o): In function `btSequentialImpulseConstraintSolver::solveGroupCacheFriendlySetup(btCollisionObject**, int, btPersistentManifold**, int, btTypedConstraint**, int, btContactSolverInfo const&, btIDebugDraw*, btStackAlloc*)':
btSequentialImpulseConstraintSolver.cpp:(.text+0x5b66): undefined reference to `CProfileManager::Start_Profile(char const*)'
btSequentialImpulseConstraintSolver.cpp:(.text+0x66d4): undefined reference to `CProfileManager::Stop_Profile()'
btSequentialImpulseConstraintSolver.cpp:(.text+0x6a97): undefined reference to `CProfileManager::Stop_Profile()'

[etc]

looks like the bullet libraries are not all linked in (or maybe the order is wrong; and, yes, they are all installed).

--alex--

[NaN]

Looks like there can be problems with linking order. Can you try the latest one?

[alex25]

Looks like there can be problems with linking order. Can you try the latest one?

gcc is particular about the linking order of static libraries. anyway, the latest version works but make install doesn't. i guess it wasn't implemented yet (?)

--alex--

[NaN]

make install is wip

[alex25]

it also seems to be missing support for the data directory (i have mine in /usr/local/share/vdrift:

Code:

tried paths: /home/romosan/.vdrift//skins/simple/fonts/freesans_noshaders.png, /usr/local/share/games/vdrift/data//skins/simple/fonts/freesans_noshaders.png, /usr/local/share/games/vdrift/data/carparts//skins/simple/fonts/freesans_noshaders.png, /usr/local/share/games/vdrift/data/trackparts//skins/simple/fonts/freesans_noshaders.png
ERROR: Error loading fonts
INFO: Exiting

--alex--

[NaN]

Use --datadir=PATH

[alex25]

make install is wip

that's an understatement... :-( anyway, the datadir option doesn't seem to work. doing 'premake4 gmake --os=linux --platform=x64 --datadir=/usr/local/share/vdrift' still has vdrift looking in the default place for it. you might also want to think of a way of installing the data directories if they are present (the way it used to be done with scon)

--alex--

[alex25]

one problem i can see with the --datadir=PATH approach is that there is no way to trigger a rebuilt of pathmanager.o (i think that's the one using the DATA_DIR variable) if i change the data directory (at least i don't see any support for that in the current Makefile that is being generated). you definitely want this.

--alex--

[alex25]

and one more thing, if you want real cross-platform support use cmake http://www.cmake.org/ (as much as i hate it). this premake thingie looks like a very crude approach to a very complex problem.

--alex--

[alex25]

To reduce the maintenance burden, we had Sconscript, codeblocks, xcode files to be kept in sync, we (NaN+antoniovazquez) have moved the codebase to premake build config tool to allow us to support a variety of build systems: http://industriousone.com/what-premake

can we have a discussion on things like this before the decisions get made? you guys might think you know everything there is to be known about everything in the world but that's highly unlikely.

--alex--

[abs1nth]

the xcode projects are quite complicated and also contain custom deployment shell scripts that can generate deployable .DMG files with one click.
while the idea of generating project files sounds nice i doubt it works well for anything but very simple apps - i am sure xcode project files generated premake/cmake/whatever will be much worse then the files we have now.

[FFuser]

the xcode projects are quite complicated and also contain custom deployment shell scripts that can generate deployable .DMG files with one click.
while the idea of generating project files sounds nice i doubt it works well for anything but very simple apps - i am sure xcode project files generated premake/cmake/whatever will be much worse then the files we have now.

My two cents here:

I agree that discussion of such a change should be discussed with developers. Apparently this has not been done.

Even if you wanted to "code" this, and deliver a proof-of-concept before discussion this should have been done in a separate git branch and not in the master. Only when the feature is complete and works better (or at least as good) than previous iteration (being just scons), it should have been merged (so "make install" works, tested by multiple people, no linking problems, ...)
I even wonder why the project switched to git if not using this workflow...?
Maybe this is just a transition problem and all developers will change to this workflow soon.

At last I think CMake is the way to go (I never heard of premake, although it seems to be the same idea, so it may be a perfect fit)
I don't know what the state is of the XCode generator of CMake (or premake), but I'm pretty sure creating deployable DMG's will be possible with it.
Even if this is not possible, why not improving CMake / Premake (or just sending bug reports / feature requests), to help others who want to use CMake with XCode. You also help yourself when you want to create your next project: You just have to write your CMake, instead of recreating your XCode project.

[abs1nth]

>but I'm pretty sure creating deployable DMG's will be possible with it

i believe it when i see it

>to help others who want to use CMake with XCode

i think the idea *sounds* nice but its fundamentally impossible to create xcode (and VS and make) projects from a single source that are just as good as the real native ones.

just as using a multiplatform GUI library for a win/mac/linux app will always just result in an app that sucks on at least one of the target platforms very hard. no amount of "helping" will fix this ever. the common dominator is just too low.

[NaN]

Thank you for your feedback.

Scons is available in master. The original(non generated) xcode project and a fixed readme will be available as soon as possible. If you experience any specific issues with scons/xcode please post them in this thread or use the issue tracker( https://github.com/VDrift/vdrift/issues ).

My sincere apologies for the inconvenience caused by the latest changes.