build.d

[Jebbs]

Libraries like Derelict and GtkD have a special build.d file that greatly simplifies the building process for their own static library files by using rdmd(and the gdc/ldc versions of rdmd).

I'd like to do something like that for DSFML. Not only will this speed up the building process by making it a single step, it is less error prone and allows users to build DSFML in different ways(They only want to use specific modules, they want to build the documentation, etc.).

Someone else is welcome to work on this, but please be warned that a new version will have to be written for when the second version of DSFML is done. only slight modifications will need to be done to get it working, though. If no one makes one by then I'll do it before I work on the documentation.

If possible I'd like it to work for Win/Mac/Linux as well as DMD/GDC/LDC.

[aubade]

I can look into this.

EDIT: Brain wiring failed me. I didn't realize build.d was a build script in and of itself.

[Jebbs]

About something you said before the edit:

GDC can't implement pragma(lib)

That really sucks. I actually came up with a great idea(partially got it working with DMD) that uses pragma(lib) in order to load the shared libraries instead of using the command line. I guess this just won't work with GDC, but it looks like pragma(lib) is supported by LDC?

Do you know if the inclusion of a pragma(lib) command cause errors when compiling with GDC or does it just ignore it?

[Jebbs]

By the way, I wanted to mention something before you/anyone jumps to far into this. I am planning on having DSFML build separate libraries for each module, so that we can link with the D library and the corresponding C shared library, and give some kind of uniform configuration when building DSFML programs.

This why it sucks that GDC doesn't support pragma(lib). With DMD, I can put pragma(lib,"dsfml-xxx-2"); in the source for the static libraries, and assuming you give the compiler/linker the right search directories it should build by only linking with the D static libraries.

[Jebbs]

Do you know if the inclusion of a pragma(lib) command cause errors when compiling with GDC or does it just ignore it?

I could use a version guard for this now that I think about it.

[aubade]

Yes. The language spec ( http://dlang.org/pragma.html ) specifies that a compiler should error out when it runs into an unsupported pragma and recommends version guarding them. Though at least DMD and GDC have command-line flags to change that behavior.

This'll give me an excuse for setting up an LDC install on linux too. Incidentally, it shouldn't be too terribly difficult to set up the script to compile .d now, but be easily adaptable to /*.d in the future.

[Jebbs]

There are a couple of topics I would like to discuss before we get too much work done.

1. Interface Files
This is partially related to another topic I wanted to discuss, but I have been considering the build script making .di interface files. There are a couple reasons I am thinking about this. Personally, I like the idea of using di files. They work for all import statements, but the file size is smaller so they're easier to parse keeping build times as short as possible. It makes sense that something which is essentially D's version of a header file get's used for imports with a library.
The other topic this relates to is that I want to make the directories within the main DSFML\ directory make sense. Especially when setting up a project. If we have DSFML\src\ for all source code, I think it makes a whole lot of sense to make a DSFML\import\ and have it filled with di files when the user builds the shared libraries. We're already automating the building anyways, why not auto build them too? Setting an import path to DSFML\import\ is very clear as well.

Of course, we don't actually need to use them. I just think it's a cool relatively unused feature. :P
Importing the source directly is fine. too.

2. Directory Naming
I'm pretty sure that when the build script builds the individual static libraries themselves, they should go into DSFML\lib\ but what about the source? 1. needs to be decided on first. If we decide we want interface files, DSFML\src\ makes the most sense, but what if we don't? Should we opt to put the source in DSFML\import\ anyways?(even though that kind of bugs me) Should we leave it in DSFML\src\ and have users add that to their import path?(Slightly less irksome IMO)

3. Command Line Arguments
We should decide early how we want command line arguments to alter how/what actually builds. I'm thinking we could use "doc" to build documentation, as in rdmd build.d doc. For building specific SFML modules I was thinking we could use "lib" followed by the names of the packages they want to build, so rdmd build.d lib system window would only build the dsfml-system and dsfml-window libraries. Perhaps we could also have "all" to build both libraries and documentation.

[aubade]

Hm. Well, it wouldn't theoretically be too hard to add another command to the build script. I'm probably going to swipe Derelict's build.d and build on that.

I'd recommend having some sort of visual distinction between... what to build with, and what to build them into. So, for example, to build everything ever, you'd do something along the lines of:

rdmd build.d --lib --doc --import system window graphics sound network

I'd vote we leave the source in src/. Then have import/ doc/ and lib/ for storing the generated .di files, ddoc output and libraries respectively. :)
On linux, build systems often also include an installation tool, but given that DMD and GDC use completely different standard install directories for their standard import paths /usr/include/dmd and /usr/include/d/, respectively, that might not be a particularly feasible thing.

[Jebbs]

I don't know if you noticed, but there is going to be a SFML Game Jam that starts in about a week. In preparation for that I'm going to bust a couple of things out in the next couple of days so that the library is as easy as possible to jump into. The build script will be one of those things, and I'll see if I can get it done before this Friday. At least a version that auto builds all of the modules. It'll probably be DMD only for the time being since I expect most people that use D are probably using regular old DMD.

[Jebbs]

The build script is done, but I wasn't able to get it tested in time before the game jam started, so for now I'll leave it out. I will finish testing one the jam is over.

[Jebbs]

It took a while, and I was very busy finishing up classes for the term, but in the experimental branch I did upload a build.d for building static dsfml libraries. It works fine for me on Windows, but I haven't had time to set up a Linux or OSX development systems.

I'm busy finishing up the last of what I want to have done for the second version of the binding, so unless you want to do anything with this it'll stay like it is for the time being.