[aldacron]

I've just uploaded a ton of modifications to the trunk. Most of them will not affect most users. Unless you want to use Tango with Derelict on Linux, there's no need to update right now. In fact, I advise you not to unless you explicitly want to try out Tango and Derelict on Linux (not Windows -- see below).

The Build Script

First, before getting into the Tango stuff, I want to talk about the build script. It has always been a sort of hacked together bit of code. The changes I made to it a couple of weeks ago were no different. But given the problems I was having with the new changes (i.e. supporting DMD and GDC in addition to Bud) and with the growing number of build tools available, I decided to overhaul the script yet again.

The new version of the script is much easier to maintain. The biggest change is that it's more organized so that it's easier to read. I also went from 100% free-functions to a mixed approach, using a Builder class for compilation. I temporarily removed support for building without Bud, but with the new design it will be easy to add support for other tools. I intend to do so eventually: rebuild, DMD, and GDC will all be supported at some point.

As part of this build script overhaul, I renamed all of the text files that are used to pass options to Bud. Where before you say build_*.txt in the top-level directory, and a forbuild.txt in each package directory, you will now see bud_*.txt and fobud.txt. This doesn't directly affect anyone, really, unless you are developing a new Derelict package. So when you want to change config options, those are the files to look for now. I am considering whether or not to take compiler-specific options out and put those into different files.

Additionally, I've added a new command line option to the build script (which I forgot to document in the commit log). When building the libraries with Bud, the script creates a temporary Build Response File. Upon successful compilation, it deletes the file. If you want to keep it around even when compilation was successful, just pass 'noDelBRF' somewhere on the command line and the temporary file will not be deleted.

Since bud is once again the only build tool supported by the build script, you don't need to pass 'bud' on the command line. The script will default to 'bud' right now. This behavior will change in the future, when support for direct compilation is added back in. If you still use 'build' as the name of the executable, pass that on the command line and it will be used in place of 'bud'.

Tango Support

This has been a bitch to implement. Actually, implementing it in the packages was easy. Only three packages required changes (DerelictUtil, DerelictGL and DerelictSDLMixer). The changes to DerelictGL were extensive, since every extension module made use of std.string from Phobos. I updated them all automatically, though, with a simple script I wrote with Tango

To facilitate compatibility with both Phobos and Tango, I added a new module to DerelictUtil -- wrapper.d. It provides wrappers for Phobos/Tango functions used by Derelict. Anywhere in Derelict that a Phobos call was made, it was replaced by a call to a new wrapper method. In the future, when adding packages to Derelict, these functions should be used rather than Phobos or Tango functions. If something you need is not wrapped, it should be added.

Additionally, because of issues with Tango's Win32 modules (i.e. they were removed before the beta release), I decided to make Derelict completely independent from any external Win32 modules. To do so, I added a new wintypes.d module to DerelictUtil. Both the loader in DerelictUtil and the modules in DerelictGL use this module now. Again, when adding new packages this module should be used in place of any other when Win32 types and declarations are needed. If something is missing from the module that your package needs, just add it.

Now, for the caveats. Tango support is broken on Windows. It's unfortunate, but I kept encountering some inexplicable errors when trying to build the new packages into an app with Bud. I encountered similar errors when attempting to add Tango support to the build script. So, for now, you can only use Derelict with Tango on Linux. Additionally, Tango support in the build script is incomplete. So, to use Tango with Derelict on Linux, you need to build your applications with a build tool such as Bud, Rebuild, or DSSS. Without any means to test a Tango-ized build script, I decided to put it off for a bit. Once the Windows errors get resolved, so that I can actually test the script, I'll implement it fully.

I was able to test the new build script with bud on Windows without Tango. Compilation is fine and the sdl_ex1 example executes fine as well. I did not test anything else. Because of the Tango errors, Tango support is 100% untested. I don't even know if it compiles. So, if you are trying this out on Linux, please, please, please let me know if you encounter any problems.

Documentation

The docs have not yet been updated. So that means that both the documentation for compiling with the build script and the docs for Derelictifying a package are out of date. It also means that there is no documentation at all for the new Tango support.

Consider the Trunk Unstable

For the near future, you can consider the trunk unstable. I didn't think a branch or a tag was warranted, as things still work fine when not using Tango. Still, unless you want to play with Derelict and Tango on Linux, just don't bother updating until I get all of the kinks worked out.

As always, let me know if you have any problems.
_________________
The One With D | The One With Aldacron | D Bits

[proj]

Hi this is my first post and I have really just been into D and derelict for a short time now. I am using OSX 10.3 so had to make some changes to the buildme.d script in TRUNK to support the differences in mac object tools. Also I added similar functionality to your noDelBRF option but to also support leaving object files between compilations and putting them in a seperate compilation path depending on release or debug.

I have one fix for endian.d in SDL to fix a compile error on mac ppc:

[odeamus]

I got a simple SDL window in OpenGL mode working on windows, with Tango of course.

I had to edit four files in derelict and had to copy the std.c.windows.windows module from phobos to my project.

Here are the changes I made.

[aldacron]

[aldacron]

Thanks for the corrections. Just to point out something, though:

[odeamus]

[aldacron]

Okay, I've confirmed that things do compile with Rebuild on Windows. I compiled and executed sdl_ex1 without a problem with Rebuild, but still get an error when using Bud.

So, to revise what I said above, if you are on Windows and want to try out Derelict with Tango, you can do so as long as you use Rebuild (or, I assume, DSSS). I won't be adding support to the build script for this just yet.
_________________
The One With D | The One With Aldacron | D Bits

[proj]

[kris]

[aldacron]

[kris]

Ahhh ... I've seen Build do all kinds of strange things when presented with multiple version statements like that example has

In many cases, I would move version(UnitTest) {} code up to the top of a module to get them to 'take'. That's perhaps got something to do with the issue here, and would explain why rebuild works instead (it used the compiler front-end).

[Deltafire]

For Tango:

[aldacron]

I assume that's for the libdl declarations. I had intended to remove the std.c.linux.linux bit and just use the local declarations that were already there. That's done now, so there should be no dependence on the linux modules from Tango or Phobos. Let me know if it doesn't work.
_________________
The One With D | The One With Aldacron | D Bits

[volcore]

Doesn't work. I'm getting a multiple definitions error in the linker stage. I've patched my local version much like Deltafire proposed, and that works very well.

Also, there is another issue, with recent tango svn versions, is that demarcate has been deprecated and replaced by split, much like the phobos split function. This leads to the following patch:

[aldacron]