K-ballo changed the topic of #ste||ar to: STE||AR: Systems Technology, Emergent Parallelism, and Algorithm Research | stellar.cct.lsu.edu | HPX: A cure for performance impaired parallel applications | github.com/STEllAR-GROUP/hpx | Buildbot: http://rostam.cct.lsu.edu/ | Log: http://irclog.cct.lsu.edu/
<K-ballo>
somehow hpx core gained 200mb of debug bloat in the last week or two
<hkaiser>
K-ballo: uhh
<hkaiser>
K-ballo: could you narrow it down ?
hkaiser has quit [Quit: bye]
<K-ballo>
likely a new module
<ms[m]>
K-ballo: one of the three main shared libraries or in total (i.e. including the intermediate static libraries)?
<K-ballo>
the entire "Core" vs folder
<K-ballo>
modules, components, plugins, etc
<K-ballo>
what you get when disabling tests, tools, docs, and examples
<K-ballo>
it's all the libs and dlls, but also their debug information
<K-ballo>
older versions of master that previously built now fail, new msvc version must have introduced a fix/regression
diehlpk_work has joined #ste||ar
hkaiser has joined #ste||ar
<ms[m]>
K-ballo: it's possibly not actual added bloat but just redundant bloat...? without using object libraries every module has an unnecessary static lib built, which isn't actually installed
<ms[m]>
the real check would be to see if the shared libs/dlls have actually grown in size
<ms[m]>
I didn't want to start moving things around without you having a look first
<hkaiser>
ms[m]: thanks, I'll have a look
<hkaiser>
not sure what we changed that created this issue, though, including apply_implementations.hpp in various places might help avoiding the circual deps, though
<K-ballo>
ms[m]: that's why my first guess was new modules
<K-ballo>
interesting, the error I'm seeing in master is related to apply impl too, seems there are cyclic includes
<K-ballo>
nevermind, I just realized I'm being affected by generated headers left behind, including entire modules, causing the cycles
<K-ballo>
we may need to look into removing generated headers that no longer exist at configuration time
<hkaiser>
K-ballo: yah, I was hit by that as well
<hkaiser>
K-ballo: otoh, you might not want to always delete all generated files as this would possibly trigger a full rebuild
<K-ballo>
no, just remove those that no longer exist
<hkaiser>
but we could a special target that does that
<hkaiser>
ahh, makes sense
<K-ballo>
these generated directories are controlled entirely by the module, should be doable
<hkaiser>
nod
<K-ballo>
if the module has a list of generated files, it can just delete anything not in it
<hkaiser>
just remove the whole directory if the module is not in the list (anymore)
<K-ballo>
that's not sufficient, wouldn't help my case at least
<hkaiser>
ok
<K-ballo>
going back to an older commit effectively "undeprecates" headers, but modules still exist
<K-ballo>
but the redirection headers remain, and for some reason appear to take precedence over the normal ones
<K-ballo>
I don't actually know how to handle the entire module disappearing, but it shouldn't matter since in that case the include paths won't be in effect
<hkaiser>
K-ballo: we have a list of modules, just iterate over the subdirectories and see if those are in the list
<K-ballo>
good news, the extra 200mb of bloat isn't real, it was being caused by global module includes from leftover files