Angband.oook.cz
Angband.oook.cz
AboutVariantsLadderForumCompetitionComicScreenshotsFunniesLinks

Go Back   Angband Forums > Angband > Development

Reply
 
Thread Tools Display Modes
Old December 4, 2009, 00:16   #1
konijn_
Hellband maintainer
 
konijn_'s Avatar
 
Join Date: Jul 2007
Location: New York, the Big Apple
Age: 41
Posts: 367
Donated: $120
konijn_ is on a distinguished road
For the love of grep

Rant, not for sensitive souls.

Seriously,

\biteme\angband-3.1.1-src\src>grep distribute_ *

attack.c: distribute_charges(o_ptr, i_ptr, 1);
store.c: distribute_charges(o_ptr, &picked_item, amt);
store.c: distribute_charges(o_ptr, &sold_item, amt);
store.c: distribute_charges(o_ptr, &dropped_item, amt);

I've actually spent 12 minutes agonizing that I was going mad, or that zip does not work or my filesystem just went bonkers, or maybe its all just an illusion. Sigh...

\biteme\angband-3.1.1-src\src>grep --recursive distribute_ *
attack.c: distribute_charges(o_ptr, i_ptr, 1);
monster/melee1.c: distribute_charges(o_ptr, i_ptr, 1);
object/obj-util.c: * too. We split off the same amount as distribute_charges.
object/obj-util.c: distribute_charges(o_ptr, i_ptr, amt);
object/obj-util.c:void distribute_charges(object_type *o_ptr, object_type *q_ptr, int amt)
object/object.h:void distribute_charges(object_type *o_ptr, object_type *q_ptr, int amt);
store.c: distribute_charges(o_ptr, &picked_item, amt);
store.c: distribute_charges(o_ptr, &sold_item, amt);
store.c: distribute_charges(o_ptr, &dropped_item, amt);

I am back to Hellband, I feel like Leon for some bizarre reason ;]
And I noticed that hellband is missing distribute_charges, so I was trying to find it... Why make life for maintainers so hard ?? Really...

That's just the tip of the iceberg of course.
I dont think the current crop of the cream appreciates how my variants (others?) leech of Vanilla, I cant do that when the codebase keeps changing drastically.

Cheers,
T.
__________________
* Are you ready for something else ? Hellband 0.8.8 is out! *
konijn_ is offline   Reply With Quote
Old December 4, 2009, 00:57   #2
Nick
Vanilla maintainer
 
Nick's Avatar
 
Join Date: Apr 2007
Location: Canberra, Australia
Age: 53
Posts: 7,189
Donated: $60
Nick is on a distinguished road
Yeah, I'm not planning a move away from the flat src directory any time soon - except I already have for win and gtk. Damn.
__________________
One for the Dark Lord on his dark throne
In the Land of Mordor where the Shadows lie.
Nick is offline   Reply With Quote
Old December 4, 2009, 00:57   #3
Derakon
Prophet
 
Derakon's Avatar
 
Join Date: Dec 2009
Posts: 8,500
Derakon is on a distinguished road
So if I understand you correctly, your complaint is that distribute_charges got moved to a subdirectory, and you couldn't find it because you expected the source tree to be flat?

Personally, I'm all for cleaning up source code organization into hierarchies wherever possible, though it's possible this change could have been better-communicated. Cleaner code is easier-to-modify code, which makes for more community engagement. The problem comes when "community engagement" results in everyone having their own out-of-date fork of the main codebase.
Derakon is offline   Reply With Quote
Old December 4, 2009, 08:18   #4
Magnate
Angband Devteam member
 
Join Date: May 2007
Location: London, UK
Posts: 5,057
Magnate is on a distinguished road
Send a message via MSN to Magnate Send a message via Yahoo to Magnate
Heh, that got me the first time I checked out SVN too. I was grepping for tot_mon_power, and I was halfway through an email to Takkaria yelling "what have you done with it??" before I spotted the subdirs.
Magnate is offline   Reply With Quote
Old December 4, 2009, 12:01   #5
Dean Anderson
Adept
 
Join Date: Nov 2009
Posts: 124
Dean Anderson is on a distinguished road
Quote:
Originally Posted by Derakon View Post
Personally, I'm all for cleaning up source code organization into hierarchies wherever possible, though it's possible this change could have been better-communicated. Cleaner code is easier-to-modify code, which makes for more community engagement.
The problem I have with the current hierarchical source code setup is twofold:

1) Having different header files in different subfolders with identical names (particularly generic names like "constants.c" or "types.h") is not cleaner. It gives greater cause for confusion ("Which "types.h" am I currently editing? Did I just add that code to the wrong file?")

2) Different compilers and IDEs have different conventions when it comes to include paths; for example on Windows the current source works as-is if using NMAKE, but doesn't work from Visual Studio - because one of them looks for #included files at the level of the project's root directory and the othe looks for them at the same level as the file being compiled. Therefore people using different development environments simply can't use the code as-is and they are forced to fork it.

A flat file structure is the lowest common denominator. It doesn't allow "cleaning" organisation, but also doesn't allow "obfuscating" organisation; and it should simply consistently work on all systems without changes - which in my opinion is a better goal to aim for.
Dean Anderson is offline   Reply With Quote
Old December 5, 2009, 12:42   #6
AnonymousHero
Veteran
 
AnonymousHero's Avatar
 
Join Date: Jun 2007
Posts: 1,365
AnonymousHero is on a distinguished road
Quote:
Originally Posted by Dean Anderson View Post
2) Different compilers and IDEs have different conventions when it comes to include paths; for example on Windows the current source works as-is if using NMAKE, but doesn't work from Visual Studio - because one of them looks for #included files at the level of the project's root directory and the othe looks for them at the same level as the file being compiled. Therefore people using different development environments simply can't use the code as-is and they are forced to fork it.
This most often happens when people mistakenly use
Code:
#include <bla.h>
rather than
Code:
#include "bla.h"
The angle brackets form should ONLY be used for system header includes.
Any compiler/IDE which doesn't handle the latter form properly is broken and should be avoided at all cost.
AnonymousHero is offline   Reply With Quote
Old December 5, 2009, 13:45   #7
Dean Anderson
Adept
 
Join Date: Nov 2009
Posts: 124
Dean Anderson is on a distinguished road
Quote:
Originally Posted by AnonymousHero View Post
This most often happens when people mistakenly use
Code:
#include <bla.h>
rather than
Code:
#include "bla.h"
The angle brackets form should ONLY be used for system header includes.
Any compiler/IDE which doesn't handle the latter form properly is broken and should be avoided at all cost.
According to the C spec, #include "blah.h" should look in the "current directory" for the blah.h file.

Some IDEs always treat the folder containing the project as the "current directory" regardless of whether the file currently being compiled is in that folder or is in a subfolder.

Some IDEs always treat the folder containing the file currently being compiled as the "current directory" regardless of whether that is the main project folder or not.

Some compilers treat the directory from which the compiler was invoked as being the "current directory" regardless of where any of the files being compiled are.

Which of those are you calling "broken"?

Because they're all following the C spec by looking in the "current directory". It's just that the location of the "current directory" is implementation specific.

And that's a good argument for having a flat file structure - to avoid as many implementation specific issues as possible.
Dean Anderson is offline   Reply With Quote
Old December 5, 2009, 14:14   #8
d_m
Angband Devteam member
 
d_m's Avatar
 
Join Date: Aug 2008
Location: Philadelphia, PA, USA
Age: 38
Posts: 1,516
d_m is on a distinguished road
Quote:
Originally Posted by Dean Anderson View Post
According to the C spec, #include "blah.h" should look in the "current directory" for the blah.h file.

Some IDEs always treat the folder containing the project as the "current directory" regardless of whether the file currently being compiled is in that folder or is in a subfolder.

Some IDEs always treat the folder containing the file currently being compiled as the "current directory" regardless of whether that is the main project folder or not.

Some compilers treat the directory from which the compiler was invoked as being the "current directory" regardless of where any of the files being compiled are.
In all of these cases I think it is possible to pass an include path to the project's base.

I don't have a copy of Visual Studio, but it looks like under Project Settings there should be an option called "Additional Include Directories" where you should be able to specify the project's base directory.

Does something like this work?

(Disclaimer: I began working on Angband after the "great relocation" occurred, and I'm not defending it, but just trying to help you get things working.)
__________________
linux->xterm->screen->pmacs
d_m is offline   Reply With Quote
Old December 5, 2009, 19:01   #9
Dean Anderson
Adept
 
Join Date: Nov 2009
Posts: 124
Dean Anderson is on a distinguished road
Quote:
Originally Posted by d_m View Post
I don't have a copy of Visual Studio, but it looks like under Project Settings there should be an option called "Additional Include Directories" where you should be able to specify the project's base directory.

Does something like this work?
Not really - since the problem is the opposite way around to the one that that would solve. You can easily specify the project's base directory, but the #include statements assume that there's no such thing as a base directory and that every file has its own subfolder as a base directory.

Even then, you could specify additional directories to search in, and it would find all the files. Except that won't work because someone decided to have multiple files with the same name in different subdirectories.

So even if you added each of the subdirectories as additional include paths, you'd guarantee that it would find (for example) "types.h" or "constants.h" - but you'd have no idea which of each of those files it was going to find first.

Don't get me wrong. It's not a difficult thing to work around. I simply work around it by renaming the files (e.g. I rename the "types.h" in the "player" subfolder to "p-types.h", and rename the "types.h" in the "object" folder to "o-types.h", and so on) and then move them out of the subdirectories so that I have a flat file structure. Then I update all the #include statements to reference the renamed files.

Like I said, not difficult - but it's fiddly and tedious. And it breaks diff and patch compatibility with the standard source code, since files are now in different places with different names.
Dean Anderson is offline   Reply With Quote
Old December 6, 2009, 00:47   #10
zaimoni
Knight
 
zaimoni's Avatar
 
Join Date: Apr 2007
Posts: 590
zaimoni is on a distinguished road
Quote:
Originally Posted by d_m View Post
In all of these cases I think it is possible to pass an include path to the project's base.

I don't have a copy of Visual Studio, but it looks like under Project Settings there should be an option called "Additional Include Directories" where you should be able to specify the project's base directory.

Does something like this work?

(Disclaimer: I began working on Angband after the "great relocation" occurred, and I'm not defending it, but just trying to help you get things working.)
As stated, no (nor is there a reason why it should work, since the same types.h is found first regardless of the subdirectory). Visual Studio is not precise enough to allow specifying per-directory or per-file include directories, which would bypass this.

That said, NMAKE is not that painful; I would just assume that if using MSVC++ use the nmakefile to get the job done and move on.

Takkaria's reorganization also breaks OpenWatcom, by having multiple object files with the same file name land in the main build directory. But we already had the ruling (on the forum) from Takkaria that there is no intention to allow V to build under OpenWatcom, so that's a non-issue.
__________________
Zaiband: end the "I shouldn't have survived that" experience. V3.0.6 fork on Hg.
Zaiband 3.0.10 ETA Mar. 7 2011 (Yes, schedule slipped. Latest testing indicates not enough assert() calls to allow release.)
Z.C++: pre-alpha C/C++ compiler system (usable preprocessor). Also on Hg. Z.C++ 0.0.10 ETA December 31 2011
zaimoni is offline   Reply With Quote
Reply


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
It must be love (first post) cofresi Vanilla 4 November 5, 2009 20:00
To love the Rogue shevek AAR 9 May 30, 2009 19:28
How much do you love... Vanilla? Larvitz Vanilla 3 January 31, 2009 04:07
[Zangband] A Love Letter... ElectricPaladin Variants 9 May 14, 2008 18:44
Love The New Windows Console Patch Malak Darkhunter Vanilla 0 December 8, 2007 19:50


All times are GMT +1. The time now is 11:08.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.