Working On Upgrade To Premake4

[janwas]

Philip helped me with some things and it works now!

Great news, congratulations and thanks, Philip, for the assist!

The patch looks good. Feel free to commit, as far as I'm concerned.

Attaching system_info.txt to verify it does whatever it needs to do.

Looks good except for the CPU frequency. Intel CPUs mention their

intended clock rate in the brand string, but it'd be nice to measure the

actual frequency (to detect over/underclocking) at runtime.

We actually have code to do that, it's just not being called.

I intend to fix that later today.

[Yves]

Tested your patch on OS X, both gcc and xcode3 projects are working with PCH now That leaves the xcode3 test project, which fails to build:

/Users/ben/0ad/build/workspaces/xcode3/obj/test_Release/test.build/Script-9607AE1010C857E500CD1376.sh: line 58: ../../build/bin/cxxtestgen.pl: No such file or directory

Thank you for testing.

It seems to be a similar problem as the relative path issue with precompiled headers.

The directory structure was changed a little bit during the integration into svn (premake4.lua went up one level).

That seems to be the reason why we get problems with parts of the code that don't handle paths correctly.

I don't know if I have time to fix this one because I'm preparing for departure this evening. I'm going to be on holyday the next three weeks.

[Ykkrosh]

The directory structure was changed a little bit during the integration into svn (premake4.lua went up one level).

Yeah, I thought it was better to keep it where the old premake.lua was, and to keep the premake4/ directory a clean copy of the Premake 4 sources rather than mixing in our own files.

[Ykkrosh]

Clang says

precompiled.h
clang: warning: treating 'c-header' input as 'c++-header' when in C++ mode, this behavior is deprecated

which I think means it wants "-x c++-header" on the command-line when compiling the .h file. (Our old Premake PCH modifications did that.)

[historic_bruno]

OK, here's a patch (for SVN trunk) that fixes the XCode test project's shell script. VS and XCode need the same path adjustment so I combined the two.

cxxtestgen-xcode.patch

[k776]

I've been having issues on my macbook. When I use the update-workspaces-new.sh script for Premake 4 support, and I compile everything, there is no errors, but the binary binaries/system/pyrogenesis is no longer being created. When I removed the old one, and ran make again, it worked with no errors, but the binary still doesn't exist.

It does seem to be making a binaries/system/pyrogenesis.app package, but when I run it, I get an alert box saying it failed to load, and if I hit report, the following shows up: http://pastie.org/2265572

If I go into the package, and try run binaries/system/pyrogenesis.app/Contents/MacOS/pyrogenesis binary manually, I get the same error. Copying the binary to binaries/system also has the same issue.

So right now, using the new premake 4 stuff, I'm unable to play the game after compiling.

Any ideas?

Edit: Added more details about the error

Edit 2: Seems I get this error when using the old premake 3 as well.

Edit 3: Looks like an issue with SpiderMonkey. otool -L on the premake 3 binary looks like it's looking for spidermonkey in /usr/local/lib rather than the current binaries directory

[historic_bruno]

Edit 3: Looks like an issue with SpiderMonkey. otool -L on the premake 3 binary looks like it's looking for spidermonkey in /usr/local/lib rather than the current binaries directory

The Spidermonkey build should be fixed now so that it uses a relative path instead of /usr/local/lib (same fix we used for ENet). You'll still have to copy pyrogenesis from the app package to /binaries/system/. In my opinion the package serves no purpose and only makes the build process more complicated by breaking the paths. It's worth looking into for releases if anyone can be bothered.

[historic_bruno]

One additional issue is that the troublesome DELAYLOAD issue is back, it appears some changes were lost in 9830. (Maybe we need to add a list of exceptions for delayed loading?) Removing openal from the DELAYLOAD options seems to work.

[Chakakhan]

I had problems with the delayload on opengl and taking them out solved the problem, but it really shouldn't require that. Delayload is just a lazy load mechanism and this kind of problem probably indicates a dependency issue of some type. I will run the dependency walker app on it when I get home and see if that shows some problems.

So a short term fix is to remove the delayload on opengl, but we should dig a little deeper and fix the root problem.

EDIT: Ok, so everything is working fine for me with VS2010 Ultimate on Win XP 32. I just checked out the latest and did a complete rebuild. No errors, no problems at all. I ran depends and saw nothing unusual either (which I wouldn't expect since it is all working fine for me).

[Sayyan]

As discussed on IRC, removing the DELAYLOAD on OpenAL fixes the issue for me. I'm running on 64bit Windows 7 as is historic_bruno (I think.) Once I've finished wrestling with the summary screen I'll take a look with Dependency Walker.

[janwas]

If I had known how much trouble delay loading would be, I might have Just Said No

At least one DLL - user32 - refuses to be loaded more than once (this can happen if you delay-load something that pulls in user32 before any of its other dependencies loads, and then unload it again), and now we have the OpenAL issue.

In this case, delay-loading OpenAL only helps when launching with -nosound or the old -quickstart, so it's safe to disable permanently.

[Yves]

I'm back from holiday and will have some time for working on the remaining problems this week.

Today I've looked into the path issues with cxxtestgen and also the patch by historic_bruno (thank you!).

The root cause of the problem is that the relative path is relative to premake4.lua and not to the project files.

In those environments using customizations of premake for test-generation, this is no problem because premake handles it internally.

I'm suggesting a slightly different solution than historic_bruno which should keep working when moving premake4.lua or the project-directory and also is a bit more self-explaining in my opinion.

I've also discovered that the makefiles use an absolute path to cxxtestgen which is not good. Accessing cxxtestpath via prj.cxxtestpath instead of prj.solution.cxxtestpath changes this.

The changes from my previous patches are also included in this one. I've tested compiling on Linux, Mac and Windows. "premake4 embed" has already been done (script.c is included), but the prebuilt premake4.exe will have to be rebuilt and updated.

Could someone please review and apply the patch?

Btw. I couldn't start 0ad on windows because it always failed calling JS_CallFunctionName with the "init" function.

Is this a known bug?

pch_cxxtest_cleanworkspaces_v4.patch

[historic_bruno]

I'm back from holiday and will have some time for working on the remaining problems this week.

Today I've looked into the path issues with cxxtestgen and also the patch by historic_bruno (thank you!).

The root cause of the problem is that the relative path is relative to premake4.lua and not to the project files.

In those environments using customizations of premake for test-generation, this is no problem because premake handles it internally.

I'm suggesting a slightly different solution than historic_bruno which should keep working when moving premake4.lua or the project-directory and also is a bit more self-explaining in my opinion.

I've also discovered that the makefiles use an absolute path to cxxtestgen which is not good. Accessing cxxtestpath via prj.cxxtestpath instead of prj.solution.cxxtestpath changes this.

The changes from my previous patches are also included in this one. I've tested compiling on Linux, Mac and Windows. "premake4 embed" has already been done (script.c is included), but the prebuilt premake4.exe will have to be rebuilt and updated.

Could someone please review and apply the patch?

Welcome back, hope you had a good holiday That sounds fine by me, I don't understand all the internals of Premake by any means, so my patch was more of a workaround. A proper solution is even better. I can test your patch on Windows and OS X, but my virtual Ubuntu machine has some problems running the game. And if anyone else is brave enough to test, that's good too

Btw. I couldn't start 0ad on windows because it always failed calling JS_CallFunctionName with the "init" function.

Is this a known bug?

Sounds like the /DELAYLOAD issue mentioned above. If you want to try the latest SVN revision, I've disabled delay loading of OpenAL. (Of course it will require update-workspaces, too.)

[Chakakhan]

I had one case where I had to remove DELAYLOAD for opengl as well. Only on one machine Win7 64 bit o/s.

[Yves]

Sounds like the /DELAYLOAD issue mentioned above. If you want to try the latest SVN revision, I've disabled delay loading of OpenAL. (Of course it will require update-workspaces, too.)

Yes, that was the problem.

I had one case where I had to remove DELAYLOAD for opengl as well. Only on one machine Win7 64 bit o/s.

I'm using Win7 64bit too and it wasn't needed here.

Does anyone else have strange g++ errors when running the makefiles in parallel mode (e.g. make -j5)?

I'm using Ubuntu's default version(4:4.4.4-1ubuntu2).

g++: Internal error: Bus-Zugriffsfehler (program cc1plus)
Please submit a full bug report.
See <file:///usr/share/doc/gcc-4.4/README.Bugs> for instructions.

This happens on my Ubuntu, but I've never seen it on the Snow Leopard.

EDIT:

It's something related to pch.

I've tried gcc 4.5 which had the same problem and put some "sleeps" into the makefile, but it didn't help either.

I know exactly in which line it happens, but I don't know why...

Steps to reproduce:

1. Build everything with make -j5 (no problems).

2. Do something that causes the precompiled headers to be rebuilt (e.g. add "extern int testxyz;" to status.h).

3. run make -j5 lowlevel or just make -j5.

The relevant part including my tests with sleep:

ifneq (,$(PCH))
$(GCH): $(PCH) | $(OBJDIR)
	@echo $(notdir $<)
	sleep 5
	-$(SILENT) cp $< $(OBJDIR)
	sleep 5
	$(SILENT) $(CXX) $(CXXFLAGS) -o "$@" -c "$<"
	sleep 5
endif

and the output:

yves@yves-desktop:~/Projekte/0ad/build/workspaces/gcc$ make -j5 lowlevel
==== Building lowlevel (release) ====
precompiled.h
sleep 5
sleep 5
g++: Internal error: Bus-Zugriffsfehler (program cc1plus)
Please submit a full bug report.
See <file:///usr/share/doc/gcc-4.4/README.Bugs> for instructions.
make[1]: *** [obj/lowlevel_Release/precompiled.h.gch] Fehler 1
make: *** [lowlevel] Fehler 2

EDIT2:

Deleting precompiled.h.gch seems to work around the problem somehow.

I don't understand what's happening here. For me it looks like make and gcc are interfering somehow on precompiled.h.gch... but how?

The relevant targets depend on $(GCH), so make should patiently wait until precompiled.h.gch is successfully updated before building them.

Any Ideas?

$(GCH): $(PCH) | $(OBJDIR)
	@echo $(notdir $<)
	rm -f $(OBJDIR)/precompiled.h.gch
	-$(SILENT) cp $< $(OBJDIR)
	$(SILENT) $(CXX) $(CXXFLAGS) -o "$@" -c "$<"
endif

EDIT3: Something else...

I've closed ticket #428.

Is that ok or should I ask next time before closing a ticket?

Edited August 11, 2011 by Yves

[historic_bruno]

EDIT2:

Deleting precompiled.h.gch seems to work around the problem somehow.

I don't understand what's happening here. For me it looks like make and gcc are interfering somehow on precompiled.h.gch... but how?

The relevant targets depend on $(GCH), so make should patiently wait until precompiled.h.gch is successfully updated before building them.

Any Ideas?

$(GCH): $(PCH) | $(OBJDIR)
	@echo $(notdir $<)
	rm -f $(OBJDIR)/precompiled.h.gch
	-$(SILENT) cp $< $(OBJDIR)
	$(SILENT) $(CXX) $(CXXFLAGS) -o "$@" -c "$<"
endif

I'm getting the same problem in Ubuntu with gcc 4.5.2, even without using the -j option (old update-workspaces works fine, btw).

[Yves]

I'm getting the same problem in Ubuntu with gcc 4.5.2, even without using the -j option (old update-workspaces works fine, btw).

I've installed the newest version of gcc (4.6.1) from source and this seems to fix it.

I've compiled everything about 5 times without getting the bus-error then switched back to 4.4.5 and it happened every time again.

Do you think manually deleting precompiled.h.gch every time before it rebuilds (like shown in the last post) is a valid workaround?

I think we must find a workaround because a lot of users will be using a version of gcc with this bug.

If you agree I can write a patch to include it in premake4.

[historic_bruno]

Do you think manually deleting precompiled.h.gch every time before it rebuilds (like shown in the last post) is a valid workaround?

Will that lose the advantage of using precompiled headers?

[Yves]

Will that lose the advantage of using precompiled headers?

No. It will only delete precompiled.h.gch if it needs to be rebuilt.

As far as I understand, the file will be entirely rebuilt in this case anyway and there should be no disadvantages.

I'm going to create a patch for that tomorrow, we can then test if everything works as expected.

[historic_bruno]

Not specific to premake4, but maybe something you'd be willing to look into: http://www.wildfiregames.com/forum/index.php?showtopic=15048 ?

The AtlasUI shared lib has an incorrect relative path for gcc targets (apparently from where it's built instead of being in the same directory where e.g. ActorEditor is run).

[Yves]

I've attached the patch for working around the bus-error to Ticket #903.

[historic_bruno]

I can compile now, but I can't link because a 64bit version of wxwidgets is missing.

It looks like we'll have to add support for wxwidgets 2.9 for getting 64bit support. Simply setting arch=x86 in premake4.lua as a workaround doesn't work either because a lot of dependencies do their own architecture detection.

I think getting Atlas to compile on OS X with wxWidgets 2.8 is a lost cause, it appears the Mac Ports devs have also given up on this and are suggesting people migrate to 2.9 instead. There are other issues than this, namely the Carbon implementation (which doesn't support all 64-bit APIs) has different constructors for wxGLCanvas, so I thought maybe we could add macros for that, but this would only help older 32-bit Intel Macs building with wxWidgets 2.8, I think they could just as easily upgrade to 2.9 instead - in the very unlikely event that anyone tries. I uninstalled the wxWidgets stable (2.8.12) port and installed wxWidgets-devel (2.9.1) and it seems to build fine for me in OS X 10.6, with a few changes (r10095). Philip also made some earlier updates to get us 2.9-compatible, so I think we can focus on that.

[historic_bruno]

Is it possible to get XCode to switch the active target when changing build configuration? Like when I switch between Release and Debug, it doesn't seem to switch "pyrogenesis" and "pyrogenesis_dbg" (this doesn't seem to affect the build target, only the run and debug). I don't know if it's a premake4 problem or an XCode problem.

[Yves]

Thank you for committing the patch and for the feedback!

Is it possible to get XCode to switch the active target when changing build configuration?

I currently don't have access to my computer, but I should have time to check it this weekend.

Edited September 5, 2011 by Yves

[Yves]

I don't quite understand the problem.

We currently use the same xcode-target for debug and release builds, and the output filename and other settings are defined in the configuration.

If you switch the configuration to debug, you can right-click on Executables>pyrogenesis and select "Get info" to verify that it actually points to pyrogenesis_dbg.

The only things that don't change are the names of the target and executable displayed in xcode on the left side in the "Groups & Files" panel, which is fine in my opinion. I've verified that it actually runs the debug executable in the debug configuration and the release-executable in release configuration via "Build and Run" / "Run".

Could you elaborate on this please?