FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Big Changes Afoot

 
Post new topic   Reply to topic     Forum Index -> Derelict
View previous topic :: View next topic  
Author Message
aldacron



Joined: 05 May 2004
Posts: 1322
Location: Seoul, South Korea

PostPosted: Fri Dec 30, 2011 4:39 am    Post subject: Big Changes Afoot Reply with quote

I had originally intended to move Derelict 2 to the trunk as the "official" Derelict quite a while ago. We can see that never happened. As a result, Derelict 2 hasn't really been released, but I'm quite certain it's got more users than the trunk. Because of this, I've been reluctant to make any breaking changes. But the decision to move the project to github creates an opportunity to do so.

I think it's time to say farewell to the Derelict source tree as we know it. The current structure was set up with the idea that people could checkout individual packages more easily. That worked well with DSSS when it was still active, but today I don't think anyone actually does that. When you want Derelict, you generally pull down the whole trunk.

The downside to the structure has always been that it makes setting up import paths rather annoying. Originally, I solved the problem with a simple script that would copy the source modules in a proper hierarchy anywhere you specify. In Derelict 2, I dropped that approach in favor of having the compiler generate .di files in a configurable directory. Neither approach is ideal, really.

So the first major change I have planned is to eliminate all of the package directories and drop all of the modules under a single "import" directory. So all of Derelict will be importable out of the box just by adding $(Derelict)/import to your import path.

The second big change is going to be in DerelictGL. I *think* I can do it without breaking the external interface too badly. Most of the changes will be internal. Basically, what I want to do is to overhaul the extension system again. The current setup is really a bit of a pain to maintain. I'll have to give it some more thought, but I have a general idea.

The third breaking change is that I will be saying goodbye to D1 support. I'll be very happy to be able to get rid of all the string mixins and actually use D2 keywords. As a side effect, that also means that, for now at least, there will be no more Tango support.

But D1 and Tango Derelictophiles, have no fear. The current repository isn't going anywhere. Basically, I'll be viewing the github move as Derelict 3. Derelict 1 and 2 will still be here. Once I get Derelict 2 "finished", I will move it to the trunk and mothball Derelict 1. The existing Derelict 2 packages will continue to be maintained as long as people are using it. But I won't be adding any new packages or making any major updates to it.

Overall, I think this is the best approach, rather than moving Derelict 2 to github as it is. It does mean a good deal more work for me. But I think it's also more likely that more patches will be submitted over at github (in the form of pull requests) which, hopefully, will speed things up a bit.
_________________
The One With D | The One With Aldacron | D Bits
Back to top
View user's profile Send private message Send e-mail
doob



Joined: 06 Jan 2007
Posts: 367

PostPosted: Sat Dec 31, 2011 9:32 am    Post subject: Reply with quote

If you still want to be able to checkout individual packages, git submodules would make that possible. A git submodule is basically a separate repository with its own history included in another repository. The repository for the submodule can be used completely on its own.

When you clone a repository with submodules you need to explicitly "clone" the submodules as well. This would mean you could have a Derelict repository acting like a "parent/super" repository and then several repositories acting like submodules for the actual different libraries, OpenGL, SDL and so on. The user would then have the option to just clone the repositories he/she actually needs.

About Tango, there is a D2 port of Tango available that can be used together with Phobos, just so you know.
Back to top
View user's profile Send private message
aldacron



Joined: 05 May 2004
Posts: 1322
Location: Seoul, South Korea

PostPosted: Sat Dec 31, 2011 9:10 pm    Post subject: Reply with quote

doob wrote:
If you still want to be able to checkout individual packages, git submodules would make that possible. A git submodule is basically a separate repository with its own history included in another repository. The repository for the submodule can be used completely on its own.

When you clone a repository with submodules you need to explicitly "clone" the submodules as well. This would mean you could have a Derelict repository acting like a "parent/super" repository and then several repositories acting like submodules for the actual different libraries, OpenGL, SDL and so on. The user would then have the option to just clone the repositories he/she actually needs.


That sounds even better. I'm still very unfamiliar with git, so I need to read up on it before making the switch.

Quote:

About Tango, there is a D2 port of Tango available that can be used together with Phobos, just so you know.


Right. I don't have to include Tango support in Derelict anymore because it should work right out of the box. I can completely drop that util.compat module, something I've wanted to do for ages.
_________________
The One With D | The One With Aldacron | D Bits
Back to top
View user's profile Send private message Send e-mail
Andrej08



Joined: 31 Aug 2010
Posts: 51

PostPosted: Wed Feb 01, 2012 8:55 am    Post subject: Reply with quote

That's very nice, the new import system is especially welcome!

FWIW there are ways to eliminate having to write duplicate code in D2 (I'm referring to functions.d and the cast(void**) calls) . For example, here's a snippet of code I've used in a fork of DTK (D Tk wrapper) to load symbols dynamically:

http://pastebin.com/VadivPCZ

That pastie won't compile as-is since it's missing imports and some types, but it's just a demonstration. And it *could* be written better with less hardcoding, but I wrote it in just a couple of minutes as I was in a rush at the time.

Anywho, it's cool GL3 support is in Derelict3. I'd be cool to have some GL3 tutorials ported to D2, methinks. Smile
Back to top
View user's profile Send private message
aldacron



Joined: 05 May 2004
Posts: 1322
Location: Seoul, South Korea

PostPosted: Wed Feb 01, 2012 9:41 pm    Post subject: Reply with quote

Andrej08 wrote:

FWIW there are ways to eliminate having to write duplicate code in D2 (I'm referring to functions.d and the cast(void**) calls) . For example, here's a snippet of code I've used in a fork of DTK (D Tk wrapper) to load symbols dynamically:

http://pastebin.com/VadivPCZ

That pastie won't compile as-is since it's missing imports and some types, but it's just a demonstration. And it *could* be written better with less hardcoding, but I wrote it in just a couple of minutes as I was in a rush at the time.


Yeah, there are several ways I could make it easier on myself with string mixins. But in my experience, using them on a large scale negatively impacts compilation time. There's a huge difference in compilation times between DerelictGL3 and the old DerelictGL (which did use mixins to some extent). It's a minor issue, but I get annoyed every time I compile Derelict2 and watch the output hang a few seconds on DerelictGL.

Quote:
Anywho, it's cool GL3 support is in Derelict3. I'd be cool to have some GL3 tutorials ported to D2, methinks. Smile


It's definitely on my TODO list. I've pushed a couple of other things to the backburner to focus on this kind of thing for a bit.
_________________
The One With D | The One With Aldacron | D Bits
Back to top
View user's profile Send private message Send e-mail
Andrej08



Joined: 31 Aug 2010
Posts: 51

PostPosted: Fri Feb 03, 2012 5:33 am    Post subject: Reply with quote

aldacron wrote:

But in my experience, using them on a large scale negatively impacts compilation time.


Yeah, it might be an issue with large libs. One day DMD will have to get fast enough at compile-time so we don't have to worry about these issues. Smile

Quote:

It's definitely on my TODO list. I've pushed a couple of other things to the backburner to focus on this kind of thing for a bit.


Oh I didn't mean that you yourself had to do it. A few months ago I've ported about half the NeHe OpenGL tutorials, but I didn't realize at the time that the old OpenGL API was deprecated (I've never used OpenGL before). I'd eventually like to take a look at porting GL3 tutorials, if there are any interesting ones around for C/C++.

Btw, +1 on using a D script to build Derelict. I find D to be great for writing quick custom-made build scripts. I don't have to look into some 100-page manual of a build system to look up some custom build syntax. And build bugs are relatively easy to fix.
Back to top
View user's profile Send private message
Trass3r



Joined: 29 Feb 2008
Posts: 66
Location: Germany

PostPosted: Sun May 13, 2012 6:06 am    Post subject: Re: Big Changes Afoot Reply with quote

aldacron wrote:
So the first major change I have planned is to eliminate all of the package directories and drop all of the modules under a single "import" directory. So all of Derelict will be importable out of the box just by adding $(Derelict)/import to your import path.

Thanks a lot. And please leave it that way, no git submodules or whatever.
Disc space and network traffic aren't issues nowadays so who cares if all packages are in a single repo.

By the way, would it be possible to link some functions like OpenGL core functionality statically to reduce the size of the resulting binary?
Back to top
View user's profile Send private message
aldacron



Joined: 05 May 2004
Posts: 1322
Location: Seoul, South Korea

PostPosted: Sun May 13, 2012 7:15 pm    Post subject: Re: Big Changes Afoot Reply with quote

Trass3r wrote:
By the way, would it be possible to link some functions like OpenGL core functionality statically to reduce the size of the resulting binary?


I'd really rather not. That would mean another library to link with, meaning more support issues for me from people who are new to the concept of compile/link.
_________________
The One With D | The One With Aldacron | D Bits
Back to top
View user's profile Send private message Send e-mail
Trass3r



Joined: 29 Feb 2008
Posts: 66
Location: Germany

PostPosted: Mon May 14, 2012 5:26 pm    Post subject: Reply with quote

I see.
Though people are so dumb they don't even understand what "Failed to load one or more shared libraries: SDL2.dll - The specified module could not be found" means.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic     Forum Index -> Derelict All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group