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

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

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

Advantage to option 2 is that we could add magic to exclude
those headers for modules not built.

Advantage to both options is that we eliminate all of the
module-specific cross-module-class inclusions.

Overall logic change should be close to nill, since the
'make install' path no longer needs to be smart enough
to look throughout all of the modules/*/mod_*.h files for
the target installation. What doesn't end up in include/
wasn't needed for the target install tree anyways.

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.

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