Directory structure in /src
Moderator: PPS-Leaders
Re: Directory structure in /src
Yep, this solves exactly this problem. The problem was not at link time though but rather at run time, where windows only searches the standard paths (plus the ones in PATH) for dlls but not the path of the DLL being loaded just now. So if you load the quest plugin before the overlays plugin, overlays will get loaded automatically (but only once as fabian tested).
Under linux this should not be a problem because the libraries get path information about their dependencies (so called rpaths).
Under linux this should not be a problem because the libraries get path information about their dependencies (so called rpaths).
http://www.xkcd.com/
A webcomic of romance, sarcasm, math, and language.
A webcomic of romance, sarcasm, math, and language.
Re: Directory structure in /src
@greenman: There never was a problem with linking (of course just in one direction, crosslinking isn't supported). As reto said, the problem only occurred at runtime and this is solved now.
Linking modules in general is fine and makes sense in many cases (not in all though). For example you can add new overlay elements with new gametypes and put both, the gametype and the overlay elements, into a plugin. Then you have to link the overlays module into the new plugin. Therefore you don't have to modify existing modules if you want to add a plugin (I'm calling this intentionally "plugin" because it could be a custom game modification by a user - see my skilled drawing below).
Linking modules in general is fine and makes sense in many cases (not in all though). For example you can add new overlay elements with new gametypes and put both, the gametype and the overlay elements, into a plugin. Then you have to link the overlays module into the new plugin. Therefore you don't have to modify existing modules if you want to add a plugin (I'm calling this intentionally "plugin" because it could be a custom game modification by a user - see my skilled drawing below).
Code: Select all
Main Library
|
| /¯\
v v |
Modules |
| \__/
|
v
Plugins
Fabian 'x3n' Landau, Orxonox developer
Re: Directory structure in /src
Back to topic, let us finish the directory discussion. Oli proposed to remove the 'orxonox' folder and Reto advocated shorter paths, so I guess Olis proposal is ok for all?
Comments?
Code: Select all
src
extern
bullet
ceguilua
cpptcl
ogreceguirenderer
ois
tinyxml
tolua
libraries
core
network
tools (new)
util
main (library + executable)
modules
gamestates (new)
overlays (new)
questsystem (new)
...
Fabian 'x3n' Landau, Orxonox developer
Re: Directory structure in /src
Actually I do have a comment:
the "main" folder still bothers me because the orxonox library doesn't really have much to do with "main" (you might compare it to "core" though..). Shouldn't the orxonox library go into the library folder?
the "main" folder still bothers me because the orxonox library doesn't really have much to do with "main" (you might compare it to "core" though..). Shouldn't the orxonox library go into the library folder?
http://www.xkcd.com/
A webcomic of romance, sarcasm, math, and language.
A webcomic of romance, sarcasm, math, and language.
Re: Directory structure in /src
So you're proposing something like this?
Looks fine too, but then of course you again have a deeper directory structure for the orxonox/main library files. And we somehow lose the implicit information that the main/orxonox library is central to the whole structure.
Personally I prefer something like that (which is the same like in my post before, but with main renamed as orxonox):
What do you think?
Code: Select all
src
extern
[...]
libraries
orxonox
[...]
modules
[...]
Personally I prefer something like that (which is the same like in my post before, but with main renamed as orxonox):
Code: Select all
src
extern
[...]
libraries
[...]
modules
[...]
orxonox
Fabian 'x3n' Landau, Orxonox developer
Re: Directory structure in /src
I would also prefer to have this main/orxonox folder directly in the src directory. And I don't really care about the naming of it ^^
There are only 10 types of people in the world: Those who understand binary, and those who don't.
Re: Directory structure in /src
I always care about naming things
And I think I can agree to the proposal because plugins will probably always be an extension of the orxonox library.
So I suppose we have a consensus and you can reorder the files after both our branches have been merged (I should be around until the Sunday after tomorrow). I have moved quite some code in the build system, but there's just about 5 lines to be merged manually into moved files.
And if we're already moving stuff: What about one or two more subfolders in the core? But I guess it's probably not very clear which files to move. So the only files I could more or less clearly assign were those related to console commands (tcl stuff, command executor, functor, executor, etc.). That would be about 24 files. What do you think?
And I think I can agree to the proposal because plugins will probably always be an extension of the orxonox library.
So I suppose we have a consensus and you can reorder the files after both our branches have been merged (I should be around until the Sunday after tomorrow). I have moved quite some code in the build system, but there's just about 5 lines to be merged manually into moved files.
And if we're already moving stuff: What about one or two more subfolders in the core? But I guess it's probably not very clear which files to move. So the only files I could more or less clearly assign were those related to console commands (tcl stuff, command executor, functor, executor, etc.). That would be about 24 files. What do you think?
http://www.xkcd.com/
A webcomic of romance, sarcasm, math, and language.
A webcomic of romance, sarcasm, math, and language.
Re: Directory structure in /src
Ok, then I'll move the libraries after the merge. Thanks for the input.
But there's also quite a mess in the objects directory, especially the worldentities. But I also don't see many options, except maybe a subdirectory for graphical classes like Model, Billboard and the others. But then we're still left with a bunch of unrelated classes like PongCenterpoint or Attacher or ForceField. So we'll probably end up with either a subdirectory for each file or one big collection in the basedirectory (for t -> infinity) i.e. there's no global solution, just an iterative approach (as soon as there are enough files of a kind, move them into a subdirectory).
Yes I agree in general, but I also don't see many separable files... Of course you can always pick out some files and put them into a subdirectory, but is it helpful? It makes the inclusion more difficult (for people not working in the core) while on the other hand people which DO work in the core have a pretty good overview of the files and don't need more structure. So in my opinion it only makes sense for files which are of internal use in the core and not included in other places. And then I'm still not sure if there's an advantage.1337 wrote:And if we're already moving stuff: What about one or two more subfolders in the core? But I guess it's probably not very clear which files to move. So the only files I could more or less clearly assign were those related to console commands (tcl stuff, command executor, functor, executor, etc.). That would be about 24 files. What do you think?
But there's also quite a mess in the objects directory, especially the worldentities. But I also don't see many options, except maybe a subdirectory for graphical classes like Model, Billboard and the others. But then we're still left with a bunch of unrelated classes like PongCenterpoint or Attacher or ForceField. So we'll probably end up with either a subdirectory for each file or one big collection in the basedirectory (for t -> infinity) i.e. there's no global solution, just an iterative approach (as soon as there are enough files of a kind, move them into a subdirectory).
Fabian 'x3n' Landau, Orxonox developer
Re: Directory structure in /src
I haven't had a look at the object hierarchy files.
About the core: There is only one advantage, I agree. But there are already 97 files in the core folder (without input). That's quite a lot (please don't compare with other projects ^^).
About the core: There is only one advantage, I agree. But there are already 97 files in the core folder (without input). That's quite a lot (please don't compare with other projects ^^).
http://www.xkcd.com/
A webcomic of romance, sarcasm, math, and language.
A webcomic of romance, sarcasm, math, and language.
Who is online
Users browsing this forum: No registered users and 4 guests