View previous topic :: View next topic |
Author |
Message |
baxissimo
Joined: 23 Oct 2006 Posts: 241 Location: Tokyo, Japan
|
Posted: Fri Jan 26, 2007 12:28 am Post subject: Reorganizing GLD |
|
|
The way GLD source files are arranged doesn't really mesh well with the normal no-lib way of doing things in D.
At the very least this code in gld.d is problematic:
Code: |
version (gldLibrary) {
private import gld_.internal;
}
|
The import seems to be needed whether or not one is building a gld library.
--bb |
|
Back to top |
|
|
Bradley Smith
Joined: 20 Jun 2006 Posts: 60
|
Posted: Sat Jan 27, 2007 12:43 am Post subject: Re: Reorganizing GLD |
|
|
baxissimo wrote: | The way GLD source files are arranged doesn't really mesh well with the normal no-lib way of doing things in D. |
GLD is designed to be used in the lib way of doing things. The D newsgroups have had several discussions recently about how using libraries can result in smaller executables.
baxissimo wrote: |
At the very least this code in gld.d is problematic:
Code: |
version (gldLibrary) {
private import gld_.internal;
}
|
The import seems to be needed whether or not one is building a gld library. |
As you discovered, if you want to build a program using the GLD source files, you must include "-version=gldLibrary" in the compile commands. This version flag allows a single gld.di header to be created without pulling in all the files under the gld_ directory.
I will expand the documentation to include building using the source files.
Thanks,
Bradley |
|
Back to top |
|
|
baxissimo
Joined: 23 Oct 2006 Posts: 241 Location: Tokyo, Japan
|
Posted: Sat Jan 27, 2007 12:57 am Post subject: Re: Reorganizing GLD |
|
|
Sounds like maybe what you should have is a version gldBuildHeader or something:
Code: |
version (gldBuildHeader) {}
else {
private import gld_.internal;
}
|
|
|
Back to top |
|
|
Bradley Smith
Joined: 20 Jun 2006 Posts: 60
|
Posted: Sat Jan 27, 2007 1:42 am Post subject: Re: Reorganizing GLD |
|
|
baxissimo wrote: | Sounds like maybe what you should have is a version gldBuildHeader or something:
Code: |
version (gldBuildHeader) {}
else {
private import gld_.internal;
}
|
|
The way it is with gldLibrary is the only way I could find to allow hiding all the implementation details to be under the gld_ package. It allows GLD to be used with just one library file and one header file. The above would also require using -version=gldBuildHeader.
Either that or I would have to manually edit the gld.di file every time it was created, and I'm not willing to do that. |
|
Back to top |
|
|
baxissimo
Joined: 23 Oct 2006 Posts: 241 Location: Tokyo, Japan
|
Posted: Sat Jan 27, 2007 2:25 am Post subject: Re: Reorganizing GLD |
|
|
Bradley Smith wrote: | baxissimo wrote: | Sounds like maybe what you should have is a version gldBuildHeader or something:
Code: |
version (gldBuildHeader) {}
else {
private import gld_.internal;
}
|
|
The way it is with gldLibrary is the only way I could find to allow hiding all the implementation details to be under the gld_ package. It allows GLD to be used with just one library file and one header file. The above would also require using -version=gldBuildHeader.
Either that or I would have to manually edit the gld.di file every time it was created, and I'm not willing to do that. |
Ok. I think I finally get it. The import needs to be there when:
1. Compiling the library
2. User compiles app against gld source directly
But not when:
3. User compiles app against gld library (using .di)
You control only #1 with 'buildme.d'.
And one of 2. or 3. is going to require a version flag.
So you could strip the import altogether out of the .di file (manually as you say), and do away with the version statement protecting it.
(Sorry for repeating what you already know, but I figured I'd put it there for future users curious about how/why GLD is setup the way it is).
Now here's my thought. Editing gld.di seems like the most reasonable thing to me. It's only built using buildme.d, so it wouldn't be too hard to load up the .di after it's generated and do the equivalent of s/gld_\.internal// on it using D's regexp library.
It is really cool to be able to use GLD with just a lib and a single .di. But it would also be nice if it were easy to use as source.
Yes there are benefits to compiling libs, but on the other hand, given the rate at which D changes, I have found myself having to compile GLD again and again because of binary incompatibilities between DMD versions. Maybe that's all settled down now and the ABI won't change anymore, but it sounds to me like D is far from done evolving. |
|
Back to top |
|
|
Bradley Smith
Joined: 20 Jun 2006 Posts: 60
|
Posted: Sat Jan 27, 2007 6:30 pm Post subject: Re: Reorganizing GLD |
|
|
baxissimo wrote: |
Now here's my thought. Editing gld.di seems like the most reasonable thing to me. It's only built using buildme.d, so it wouldn't be too hard to load up the .di after it's generated and do the equivalent of s/gld_\.internal// on it using D's regexp library. |
Good idea. That is now done in version 6.
Thanks,
Bradley |
|
Back to top |
|
|
baxissimo
Joined: 23 Oct 2006 Posts: 241 Location: Tokyo, Japan
|
Posted: Sun Jan 28, 2007 6:12 pm Post subject: Re: Reorganizing GLD |
|
|
Bradley Smith wrote: | baxissimo wrote: |
Now here's my thought. Editing gld.di seems like the most reasonable thing to me. It's only built using buildme.d, so it wouldn't be too hard to load up the .di after it's generated and do the equivalent of s/gld_\.internal// on it using D's regexp library. |
Good idea. That is now done in version 6.
Thanks,
Bradley |
Excellent! |
|
Back to top |
|
|
funsheep
Joined: 24 Jan 2007 Posts: 25
|
Posted: Tue Jan 30, 2007 4:06 am Post subject: Re: Reorganizing GLD |
|
|
Bradley Smith wrote: |
Good idea. That is now done in version 6.
|
hi,
today i tried version 6. i cant compile the examples anymore. here is what i get.
version 5 works great for me.
regards,
funsheep |
|
Back to top |
|
|
Bradley Smith
Joined: 20 Jun 2006 Posts: 60
|
Posted: Tue Jan 30, 2007 4:29 pm Post subject: |
|
|
I can't reproduce that error. It looks like it is failing to link with the X Windows extensions. Do you have libXxf86vm-devel installed?
Bradley |
|
Back to top |
|
|
funsheep
Joined: 24 Jan 2007 Posts: 25
|
Posted: Wed Jan 31, 2007 12:47 pm Post subject: |
|
|
sorry, but i cant look that up on the testsystem. either my linux knowledge is too bad or because the system is not mine and i dont have admin privileges.
since version 5 works for me, you should look up the differences between these versions.
sorry i cant help much i am still learning (and currently dont have the time to work at that project full time). |
|
Back to top |
|
|
Bradley Smith
Joined: 20 Jun 2006 Posts: 60
|
Posted: Wed Jan 31, 2007 4:47 pm Post subject: |
|
|
Version 5 to version 6 was just removal of the need to build GLD with the option -version=gldLibrary.
Perhaps the admin of your linux computer changed something? Can you still build version 5 from scratch? If you can build version 5 from scratch, but version 6 from scratch fails, something very strange is going on. None of the changes should cause that behavior. |
|
Back to top |
|
|
funsheep
Joined: 24 Jan 2007 Posts: 25
|
Posted: Thu Feb 01, 2007 12:34 am Post subject: |
|
|
RESOLVED
sorry for the whole thing. we have many computers at work (all look the same), and it seems that some of them are configured differently. now i have tried to compile on several of them, on some it works other dont.
i will work that with the admins out.
thank you for your help |
|
Back to top |
|
|
|