Re: Fixing module-specific, public include/*.h file inclusion on trunk

[William A Rowe Jr <wr...@rowe-clan.net>]

On Fri, Dec 16, 2016 at 1:22 PM, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> On Fri, Dec 16, 2016 at 12:57 PM, William A Rowe Jr <wr...@rowe-clan.net>
> wrote:
>>
>> So today's primary bogus result is courtesy of is due to leaving
>> public headers hiding in modules/class/*.h paths for our builds.
>>
>> I'd suggest one of two approaches, pick a favorite solution?
>>
>>  [  ] Have the top level build copy all modules/*/mod_*.h
>>       definitions to the build tree include/ path (conditionally,
>>       based on datestamp)?
>>
>>  [  ] Make individual modules/*/Makefile[*] responsible for
>>       moving their headers into the build tree include/ path
>>       (conditionally, based on datestamp)?
>
>
> The challenge with option 2 is that we run the makefiles in
> sequence by directory name. It introduces the need to reorder
> the subdirectories by function, so that each makefile runs based
> on its dependencies (and reciprocal dependencies require the
> current /I "../foomodules/" hack.)

Decided that POLS applies here... we add all of these ../modules/foo/
paths to the unix compile command, we should do the same throughout
each and every make component in Windows (and Netware) so this
is less likely to bite us again before we entirely transition to CMake.