hkaiser 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/
<heller_>
K-ballo: why are you worried? It's an experiment...
<heller_>
K-ballo: I didn't even announce it ;)
<K-ballo>
heller_: what if the experiment doesn't fail?
<heller_>
My main motivation is to try to get a modular HPX infrastructure going
<heller_>
That's one suggestion to move towards such a thing
<heller_>
I'm not sure if it's a good thing either
<heller_>
At the end of the day, a user shouldn't notice the difference
<heller_>
K-ballo: I think moving towards different repositories makes everything more stable and faster to move forward in the end
<heller_>
And git submodules just suck
<heller_>
So this is another try...
<heller_>
K-ballo: I know you disagree here, so let's discuss this properly
<K-ballo>
I don't disagree with experimentation
<heller_>
Last time we discussed the topic of modularization, you strongly opposed to the idea
<heller_>
IIRC, the biggest issue was with those version bump commits which are needed in such environments
<heller_>
Since they generate some overhead
<K-ballo>
modularization in a git submodule sense? sure, i'm over-my-dead-body opposed to those
<heller_>
Right, so what I want to figure out now is a better way to get there
<heller_>
git submodule is very cumbersome to work with... I think mainly because it doesn't integrate well into build systems
<heller_>
And doesn't work well with hierarchies
<heller_>
So whenever there's a version bump for one of the dependencies, it should be automatically just update. This should happen without having the flexibility to conveniently override those default versions
<heller_>
By moving that to cmake, I think that's doable, and that's what I'm trying to do with the experiment
<heller_>
One side effect of this would be, hopefully, to be able to consume either all of hpx, or just some parts of it more easily
<heller_>
The integration into things like easybuild, shouldn't be a problem either
<heller_>
Or vcpkg, or conan
<heller_>
Does this make sense?
<heller_>
The modularization should then be doable on a case by case basis, allowing for a smooth transition
<K-ballo>
consuming just parts of hpx sounds great, as long as they all reside in a single repo
<heller_>
Why should I pull all of hpx if I just want some parts?
<K-ballo>
too high a cost for development, grab a piecewise release instead
K-ballo has quit [Quit: K-ballo]
hkaiser has quit [Quit: bye]
hkaiser has joined #ste||ar
hkaiser has quit [Ping timeout: 268 seconds]
nanashi55 has quit [Ping timeout: 268 seconds]
nanashi55 has joined #ste||ar
jaafar has quit [Ping timeout: 268 seconds]
nanashi55 has quit [Ping timeout: 246 seconds]
hkaiser has joined #ste||ar
K-ballo has joined #ste||ar
nanashi55 has joined #ste||ar
hkaiser has quit [Read error: Connection reset by peer]
<ste||ar-github>
hpx/fixing_3570 dde3f12 Hartmut Kaiser: Make sure HPX is usable with latest released version of Vc (V1.4.1)
ste||ar-github has left #ste||ar [#ste||ar]
ste||ar-github has joined #ste||ar
<ste||ar-github>
[hpx] hkaiser opened pull request #3573: Make sure HPX is usable with latest released version of Vc (V1.4.1) (master...fixing_3570) https://github.com/STEllAR-GROUP/hpx/pull/3573