Module expert needed

[Manfred Schwarb]

Am 07.08.2015 um 11:29 schrieb Paul Richard Thomas:
> Dear FX,
>
> I would tend to agree with you. However, the cleanup of the .smod
> files does seem like a relatively trivial addition, which could be
> done manually. That said, getting around this issue was the purpose of
> the first version of patch #3; this added the private entities in a
> second section of the .mod file. I think that anybody determined
> enough to read and interpret the compound .mod file would probably be
> able to extract the information by other means. In any case, I am not
> sure what use this information on private entities would be!
>
> I could quite easily change back to the first version -
>

Well, 99% of all users will not use submodules, at least at the moment.
They will all get the double amount of module files then.

I guess there are projects with a lot of modules. Are there any
regressions to be expected in terms of markedly increased RAM or disk usage,
or regressions in compile time? Then the unconditional writing of
.smod files  would be a no-go, me thinks.

If it is possible, even in a non-perfect way, to suppress not needed
writings of .smod files for the most common cases, I would be in favor.


Cheers,
Manfred


> Cheers
>
> Paul
>
> On 6 August 2015 at 18:11, FX <fxcoudert@gmail.com> wrote:
>>> Why, the format of .mod files hasn't changed.  Neither have their contents.
>>> Only the cleanup scripts, if any, need adjustment.
>>
>> That’s pretty much what I meant. It may seem trivial, but it’s yet another hurdle in maintaining a build system working across different compilers (and compiler versions).
>>
>> How do other compilers deal with it?
>>
>> FX
>
>
>