| View previous topic :: View next topic |
| Author |
Message |
aldacron
Joined: 05 May 2004
Posts: 1322
Location: Seoul, South Korea
|
 Posted: Thu Jun 22, 2006 6:49 pm Post subject: |
 |
|
| DMINATOR wrote: | | Thats the problem, you think that people should do something, but real people don't do it exactly the way you want it. Thats why I had a problem, thats why there should be control for a "Dumb" user. |
We're just going to have to disagree on this point, then. I believe in going the extra mile for the average computer-illiterate consumer, but a software developer should know enough to be able to find an error message in a console window, or be able to redirect it to a file if that's a problem (as it would be on Windows 98, for example, where the console windows have no scroll bars). Don't get me wrong, anything that speeds up the development process or makes things convenient is a nice feature (hence the popularity of IDEs like Eclipse), but software developers shouldn't need hand-holding.
I do not want to make the build script any more complicated than it is. It's provided as a convenience, anyway. What I will do, though, is look into the possibility of detecting an error when it occurs and stopping the build process at that point. I haven't bothered testing the return values from executing Build via process(), so if it's possible to implement something simple I'll do it. But really, if you choose not to use a console window, that's not my problem.
| DMINATOR wrote: | | I think it is an executable. When I buld buildme.d I get buildme.exe. And then I use it as normal executable. |
buildme.d is intended to be run as a script and not compiled as an executable. I'll make that more clear in the documentation. Of course, you can do what you want with it, but the intent is to make sure the user has a command prompt open when they execute the script so that they can see the error output. Perhaps I'll add a pause at the end so that people who do compile it, for whatever reason, can have a chance to see the output. |
|
| Back to top |
|
 |
DMINATOR
Joined: 20 Jun 2006
Posts: 15
Location: Tallinn, Estonia
|
| Posted: Fri Jun 23, 2006 8:58 am Post subject: |
|
|
| aldacron wrote: |
We're just going to have to disagree on this point, then. I believe in going the extra mile for the average computer-illiterate consumer, but a software developer should know enough to be able to find an error message in a console window, or be able to redirect it to a file if that's a problem (as it would be on Windows 98, for example, where the console windows have no scroll bars). Don't get me wrong, anything that speeds up the development process or makes things convenient is a nice feature (hence the popularity of IDEs like Eclipse), but software developers shouldn't need hand-holding.
I do not want to make the build script any more complicated than it is. It's provided as a convenience, anyway. What I will do, though, is look into the possibility of detecting an error when it occurs and stopping the build process at that point. I haven't bothered testing the return values from executing Build via process(), so if it's possible to implement something simple I'll do it. But really, if you choose not to use a console window, that's not my problem.
|
I still don't agree with you, but it is not the point. If you would make atleast a simple method to check for ouput results, then I would be happy  , and probably other people who may have some problems with a build process too.
| aldacron wrote: |
buildme.d is intended to be run as a script and not compiled as an executable. I'll make that more clear in the documentation. Of course, you can do what you want with it, but the intent is to make sure the user has a command prompt open when they execute the script so that they can see the error output. Perhaps I'll add a pause at the end so that people who do compile it, for whatever reason, can have a chance to see the output. |
Yep I didn't know that, glad you are going to add it. |
|
| Back to top |
|
|
aldacron
Joined: 05 May 2004
Posts: 1322
Location: Seoul, South Korea
|
| Posted: Fri Jun 23, 2006 11:03 am Post subject: |
|
|
| DMINATOR wrote: | | aldacron wrote: | | Perhaps I'll add a pause at the end so that people who do compile it, for whatever reason, can have a chance to see the output. |
Yep I didn't know that, glad you are going to add it. |
Heh, I said "perhaps"  . I haven't decided yet, though. My problem with adding a pause is that, for people who use the script as intended, it's an extra keypress. I'm so used to building and scrolling up that the one little key press is disruptive. I need to think on it a bit. |
|
| Back to top |
|
|
aldacron
Joined: 05 May 2004
Posts: 1322
Location: Seoul, South Korea
|
| Posted: Fri Jun 23, 2006 11:56 am Post subject: |
|
|
The trunk has been updated with some documentation ehancements and a modified buildme script. The script will now exit when there is an error. This is a double edged sword though, and I will explain.
Before, all libraries which had no errors were guaranteed to compile when doing a full build. After adding the exit-on-error feature, I ran into an issue with DerelictFT. Currently, there is a bug with DMD that causes forwared reference errors with DerelictFT when building in debug mode. Normally, if I need a debug mode version of the lib I would run the script with a full build, let DerelictFT fail, then build it separately in release mode. That's not going to work with the exit-on-error feature, though. To work around it, I had to add a nasty hack to the build script. I do not like hacks at all and that was almost enough to make me reconsider. But, I did it anyway.
After that I was getting warnings about explicit casts from std.c.windows.windows when building OpenGL. To work around that, I removed the -w switch from build_common.txt.
So in order to add this feature I had to add a hack to buildme.d and remove what I consider to be an important switch for all of the packages just to allow all packages to build successfully on a full build. Is that a good tradeoff? I'm not so sure. I think the old way is much preferable: keep a command prompt open, scroll up for errors, and work individually on those packages that failed to build. This way you don't halt the entire build process and you get to use -w for the other packages.
Even so, I'm going to leave it as is for now. I don't like it, personally, and am interested in feedback on it from everyone. I'm already thinking of alternatives. |
|
| Back to top |
|
|
DMINATOR
Joined: 20 Jun 2006
Posts: 15
Location: Tallinn, Estonia
|
| Posted: Fri Jun 23, 2006 12:58 pm Post subject: |
|
|
| Why don't just signal that there were errors. Let it build all the libs. After it finishes if there are any errors, pause the program and show the user a message that there were problems - check the log file for more info. I that would be an easy way to implement, and good choice from user point of view too. |
|
| Back to top |
|
|
aldacron
Joined: 05 May 2004
Posts: 1322
Location: Seoul, South Korea
|
| Posted: Sat Jun 24, 2006 9:45 pm Post subject: |
|
|
| DMINATOR wrote: | | Why don't just signal that there were errors. Let it build all the libs. After it finishes if there are any errors, pause the program and show the user a message that there were problems - check the log file for more info. I that would be an easy way to implement, and good choice from user point of view too. |
I really don't want to pause the script at the end of execution. But I think I've found a good compormise. Rather than exit on an error, the script will pause instead. This will make sure that the user will have the opportunity to see any errors that crop up. Plus, it means that a successful build will not pause at all, which is the behavior I prefer.
*** oops! I meant to quote DMINATOR last night but hit the edit button instead and overwrote his post. It's fixed now. |
|
| Back to top |
|
|
DMINATOR
Joined: 20 Jun 2006
Posts: 15
Location: Tallinn, Estonia
|
| Posted: Sun Jun 25, 2006 2:01 pm Post subject: |
|
|
| aldacron wrote: |
I really don't want to pause the script at the end of execution. But I think I've found a good compormise. Rather than exit on an error, the script will pause instead. This will make sure that the user will have the opportunity to see any errors that crop up. Plus, it means that a successful build will not pause at all, which is the behavior I prefer.
|
That is good solution. Thank you. |
|
| Back to top |
|
|
Deewiant
Joined: 26 Dec 2005
Posts: 21
Location: Finland
|
| Posted: Mon Jun 26, 2006 7:06 am Post subject: |
|
|
The original problem with the linking is still there, even though it can be bypassed by not using the libraries and having Build compile the Derelict code on every build. Namely, the "Symbol Undefined
_D8derelict4util6loader149__T13GenericLoaderVG12aa12_6f70656e676c33322e646c6cVG8
aa8_6c6962474c2e736fVG0aa0_S64_D8derelict6opengl2gl7loadAllFC8derelict4util6load
er9SharedLibZvZ13GenericLoader4loadFAaZv". (I split the long line so the Forum wouldn't break too badly.)
A simple test case is the below code. The libraries were built simply with "dmd -run buildme.d", under Windows. The code below exhibits the error with just a normal DMD compile - to fix it, one can use Build without the "-Xderelict" option thrown, so that it takes the code from Derelict D files instead of the libraries.
| Code: | import derelict.opengl.gl;
import std.stdio;
pragma (lib, "DerelictUtil.lib");
pragma (lib, "derelictGL.lib");
void main()
{
try {
DerelictGL.load();
writefln("Successfully loaded the OpenGL shared library.");
} catch (Exception e) {
writefln("Could not load the OpenGL shared library.");
}
} |
I built Derelict once without -clean and noticed that .obj files were not generated for all files, just the one specified in each "forbuild.txt". This seems strange to me, so I thought it might be that, but it didn't seem to make a difference (except in the size of the resulting .lib files) that I added each .d file to the .txt files.
It's not a show-stopper, as with Build (or doing the equivalent of what it does manually) everything seems to work fine, but it defeats the point of building the libraries in the first place. It's a strange problem, to be sure.
(It seems that every time I build a new version of Derelict, I manage to break something.  ) |
|
| Back to top |
|
|
aldacron
Joined: 05 May 2004
Posts: 1322
Location: Seoul, South Korea
|
| Posted: Tue Jun 27, 2006 7:35 am Post subject: |
|
|
| Deewiant wrote: | The original problem with the linking is still there, even though it can be bypassed by not using the libraries and having Build compile the Derelict code on every build. Namely, the "Symbol Undefined
_D8derelict4util6loader149__T13GenericLoaderVG12aa12_6f70656e676c33322e646c6cVG8
aa8_6c6962474c2e736fVG0aa0_S64_D8derelict6opengl2gl7loadAllFC8derelict4util6load
er9SharedLibZvZ13GenericLoader4loadFAaZv". (I split the long line so the Forum wouldn't break too badly.) |
This is an issue with templates and OptLink, or perhaps the OMF file format (I can't remeber which). IIRC, the workaround is to instantiate the template in the library code. I was under the impression that's what was happening in the code for each package already, but apparently that's not the case. I suppose it has to do with "alias" being used. Tom is the resident template guru, so hopefully he has a solution. I can play with it a bit, but I'm still quite clueless about D templates. |
|
| Back to top |
|
|
|
|
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
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
