Author malte
Recipients erez, florian, gabi, jendrik, malte, silvia
Date 2015-11-09.22:06:35
Thanks for the suggestions!

Regarding your last message, I think I understand the suggestion, but I don't
think I understand the underlying rationale. (Or perhaps I don't agree with it.
;-)) I don't think we should have cmake plug-ins just to justify to ourselves
that something like the option parser "is allowed to" live in a subdirectory. (I
have nothing against introducing a namespace for the "options" subdirectory:)

Based on what I've seen so far, I'm not in favour of the "core" subdirectory in
your proposal, because it doesn't seem to be a cohesive unit. I'd rather have
these files remain where they are. Then the main source directory is still a bit
of a mess of unrelated things, but I don't think it's really better to instead
have a "core" directory which is a mess of unrelated things.

I'm sure we can find additional cohesive groupings within these files if we want
to reduce the number of files in the main directory. For example, there are a
bunch of modules that are utility modules in the sense that they provide general
services that you can easily imagine using in any other C++ program that have
nothing to do with planning, such as,,,,,,,, (Some of the utilities may actually be planning-specific on
closer inspection; this is just a first impression.)

I would package the search-related code a bit differently, including,,,
and with the search code. (An argument can be made for keeping separate, just as with

Regarding directory names, I think the module currently named "search_space" has
more to do with states than with search, and I'd reflect that in the name.
Date User Action Args
2015-11-09 22:06:35maltesetmessageid: <>
2015-11-09 22:06:35maltesetrecipients: + malte, erez, gabi, silvia, jendrik, florian
2015-11-09 22:06:35maltelinkissue64 messages
2015-11-09 22:06:35maltecreate