Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are
spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the
password reset link.
Due to spam on this forum, all posts now need moderator approval.
Entire forum
➜ SMAUG
➜ SMAUG coding
➜ Compiling error?
It is now over 60 days since the last post. This thread is closed.
Refresh page
| Posted by
| Rob Harper
(108 posts) Bio
|
| Date
| Tue 08 Jul 2003 06:00 PM (UTC) |
| Message
| | Hey guys well for some reason, when I type make now, it recompiles everything everytime even if no changes have been made to all the files, all this without me typing make clean first? | | Top |
|
| Posted by
| Nick Gammon
Australia (23,173 posts) Bio
Forum Administrator |
| Date
| Reply #1 on Tue 08 Jul 2003 09:42 PM (UTC) |
| Message
| This behaviour is controlled by the file called Makefile which make reads in. I suggest looking inside that - compare it to an original copy for example.
If you have somehow set up a dependency then it will recompile things that it thinks are needed to resolve that dependency. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| David Haley
USA (3,881 posts) Bio
|
| Date
| Reply #2 on Wed 09 Jul 2003 04:28 AM (UTC) |
| Message
| Dependency checking is generally a Very Good Thing (TM), so don't get rid of it just because it's annoying to have to recompile stuff. For example, if you change mud.h, it'll recompile every source file that refers to mud.h . One reason for this is the order of data fields in your structures.
Imagine you have the following inside a structure, which is compiled for all source files:
typdef struct {
int foo;
int bar;
int splat;
} mystruct;
Now, you need a new data field in, say, act_comm.c ... let's call it bla. So you add it in between bar and splat, and obtain the following:
typdef struct {
int foo;
int bar;
int bla;
int splat;
} mystruct;
So now what happens if we don't recompile EVERY file that accesses mud.h? Every time someone tries to access splat without having recompiled mud.h, they'll actually be getting bla - or perhaps something entirely different depending on the parameters of your compiler, code, situation, etc. In any case, you won't be getting what you expect.
One solution is to simply divide up mud.h into separate, manageable units. To be sure I never understood why they stuck it all into mud.h... seems to me that it's rather inefficient, both for compile times (having to parse the whole file even if you only need, say, mystruct), and for dependency checking (since everyone includes mud.h, and the only way to change data structures, or add constants, is to edit it, every time we change it we have to recompile everything.) Could someone perhaps explain to me the advantage of having everything in one file? I know a whole bunch of disadvantages (what I said above for example) but I'm having a great deal of trouble finding advantages.
Oh, and you might also want to check file dates. If your source files have modification dates in the future - and therefore later than whatever .o (object) file you produce - then the compiler will think it has to compile it again, since the code is more recent than the object. It would be surprising if there was a dramatic difference, i.e. more than a few minutes. But, it's worth checking. |
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone
http://david.the-haleys.org | | Top |
|
| Posted by
| Meerclar
USA (733 posts) Bio
|
| Date
| Reply #3 on Wed 09 Jul 2003 07:50 AM (UTC) |
| Message
| | To answer the querry on benefits to just lumping everything into 1 file, its marginally easier to manage in 1 file and the includes are far easier with 1 file. Imagine if you put every struct, or group of related structs, into its own file. Now, imagine you have to include every struct for reference in say your magic file..... See the insanity of breaking everything into seperate files? While it does make compiling after a code change easier, the overall effect would be more detrimental than benefitial I'd think. |
Meerclar - Lord of Cats
Coder, Builder, and Tormenter of Mortals
Stormbringer: Rebirth
storm-bringer.org:4500
www.storm-bringer.org | | Top |
|
| Posted by
| Nick Gammon
Australia (23,173 posts) Bio
Forum Administrator |
| Date
| Reply #4 on Wed 09 Jul 2003 08:05 AM (UTC) |
| Message
| Strangely enough, I've never noticed it recompiling everything after I change mud.h.
So what seems to happen is, if you change mud.h it doesn't recompile, when it should, and in your case, if you don't change it, it does. Seems you have the worst of both worlds. ;) |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | | Top |
|
| Posted by
| David Haley
USA (3,881 posts) Bio
|
| Date
| Reply #5 on Wed 09 Jul 2003 02:35 PM (UTC) |
| Message
| I think the standard SMAUG makefile doesn't have dependency generation, which is the source of many a strange behavior that can't be explained.
I'm not saying put every struct into its own header file, that would be ridiculous. But, one could put all data related to a character into character.h, all data related to mudprogs into mudprog.h, and all data related to objects into object.h. The idea is to create modules out of it. I believe that is what Kalahn (if that's not how you spell it forgive me) did with the Dawn of Time code base... he split everything up. It's what I'm in the process of doing as well, but I'm redesigning things from scratch so it's a slightly different process.
See, even if you do have to include 4 files instead of one (I'm not convinced you'd have to include THAT many... or if it really bothered you, you could make magic.h and have THAT include the necessary files... and then magic.cpp would just include magic.h and you're done), it makes it very clear what the separate units are. Perhaps this is an OOP approach to things (as indeed I am trying to convert SMAUG to an OOP model), where you divide things into units which are supposed to be as independent as possible (to provide generic, reusable code), with as little dependency as possible on one another. And I think that putting everything into one header file, from a programming theory standpoint, is not a good idea, because it makes it that much harder to see where the separate units are.
Not to mention all the wasted compile time. Of course some files like magic.cpp will need a lot of what's in mud.h. But other files, such as, I dunno, save.cpp, don't really care about a lot of the information in there, other than what relates to saving/loading players and their objects. No need to bother with all the room data, the mudprog data, etc...
One example of where to separate things clearly is everything related to connections (descriptors as SMAUG calls them.) What does the object code care about the connection? And if it does, should it be redesigned so that the two are separate? (My answer is, probably.)
That's my main complaint with the SMAUG code base, in that it isn't very modularized. That makes it hard to expand beyond what it was meant to do, because of a very rigid design that has cross-references all over the place.
|
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone
http://david.the-haleys.org | | Top |
|
The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).
To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.
18,762 views.
It is now over 60 days since the last post. This thread is closed.
Refresh page
![[Go to top]](/images/gototop.gif)
top