For the love of grep

[konijn_]

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.

[Nick]

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.

[Derakon]

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.

[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.

[Dean Anderson]

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.

[AnonymousHero]

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

#include <bla.h>

rather than

#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.

[Dean Anderson]

This most often happens when people mistakenly use

#include <bla.h>

rather than

#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.

[d_m]

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.)

[Dean Anderson]

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.

[zaimoni]

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.

[Dean Anderson]

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.

NMAKE will compile the code easily enough if that's all you want to do.

But it loses you all the advantages that an IDE has for writing, managing and debugging code.

[d_m]

Oh! I had it backwards!

The problem is that there is src/types.h and src/object/types.h! I didn't realize there was still a base-level types.h, and was getting the whole problem backwards (assuming that windows couldn't find object/types.h or something).

I am going to try moving src/types.h to src/type/types.h and see if that still works. While it would not address the concern that seeing a file named "types.h" is ambiguous, it would (I think) let Visual Studio compile/debug the code, right?

EDIT: I can confirm that this change doesn't break anything on Linux. If someone with Visual Studio could confirm that doing this (moving src/types.h to src/type/types.h and changing the one use in angband.h from '#include "types.h"' to '#include "type/types.h"') actually helps anything, that would be useful.

[andrewdoull]

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.

I have to add that I agree here... I'm not in any hurry to split the existing Unangband files up in a different structure and I have single .c files that are larger than 15.5K lines of code. [Edit: Was out by a factor of 8 here..]

Andrew

[takkaria]

I have to add that I agree here... I'm not in any hurry to split the existing Unangband files up in a different structure and I have single .c files that are larger than 130K lines of code.

Andrew

I don't know how you deal with that--I find it hard not to refactor into smaller files when coding.

[Pete Mack]

Mea culpa, mea maxima culpa. I create the original subdirectory (osx), and things got out of hand after that.

Having two types.h files is a bad idea. Name the second one object_types.h. It's a lot simpler.