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/
hkaiser has quit [Quit: bye]
bita has joined #ste||ar
bita has quit [Ping timeout: 240 seconds]
hkaiser has joined #ste||ar
<K-ballo> what's the rationale behind manually provided global module hedaers?
<hkaiser> K-ballo: probably historical reasons more than anything else
<K-ballo> global module headers shouldn't be defining new stuff
<hkaiser> nod, makes sense - I guess nobody has looked into this yet
<hkaiser> for now the effort focussed on disentangling things
Yorlik has joined #ste||ar
<Yorlik> A vcpkg installed HPX 1.5.1 is now complaining when doing a debug build about being a release build, though vcpkg built a debug build too. CMAKE_BUILD_TYPE is "Debug" and confirmed as a printout at the beginning of my CMakeLists. But for some reason find_package(HPX CONFIG REQUIRED) seems to choose the release build. Is that a known issue or is there a fix for it? I used a custom port which is basically a copy from
<Yorlik> vcpkg with just mimalloc added as option and dependency.
<Yorlik> the "SET(HPX_IGNORE_CMAKE_BUILD_TYPE_COMPATIBILITY TRUE)" hack works, but ofc I want to use the debug build of HPX for my debug build.
<hkaiser> Yorlik: vcpkg should use the correct build type
<Yorlik> Well - yes. But for some reason it doesn't and I don't understand why. maybe I just have to brush my Build system for some lingering error.
<hkaiser> Yorlik: do you use the vcpkg toolchain file?
<Yorlik> But there isn't really any magic going on
<Yorlik> Yes, I do. And I see it set correctly in the cmake command args
<Yorlik> Also it prints out correctly
<hkaiser> ok
<hkaiser> talk to the vcpkg guys, they are usually quite responsive
<Yorlik> So - if there hasn't been any known issue, I'll just do a double check.
<Yorlik> vcpkg channel on slack, right?
<hkaiser> Yorlik: well, I never consume hpx through vcpkg, but for everything else it worked without issues
<Yorlik> When setting this ignore hack everything compiles just fine. I'll double check and if I find nothing I'll talk to the vcpkg people and maybe make a minimal case.
<hkaiser> yah, it might not a good idea to mix and match different builds
bita has joined #ste||ar
<hkaiser> Yorlik: have you talked to them?
<Yorlik> hkaiser: You mean on Slack?
<Yorlik> Not yet.
<hkaiser> ok
<hkaiser> let's see what they respond to the ticket
<Yorlik> Yes.
<hkaiser> they might blame us in the end, but then they might be able to suggest a resolution
<Yorlik> By the way: The hpx port should have a feature like Allocator that could be mimalloc or jemalloc (both already provided by vcpkg) Also a bunch of otrher features that wouzld correspond to HPX Build Settings
<Yorlik> My current solution is to implement a custom port - it's simple enough.
<Yorlik> To be safe I used the vanilla vcpkg port.
<Yorlik> Of HPX in the ticket, I mean.
<hkaiser> Yorlik: sure, if you would like to contribute such changes, I'd be happy to create a PR to them
<hkaiser> I just didn't care enough to understand how to do this
<Yorlik> I'd have to dig deeply into the HPX build scripts then. Probably trhere is a simple stupid reason why the CMAKE_BUILD_TYPE is lost.
<hkaiser> that's not what I meant
<hkaiser> I was referring to 'The hpx port should have a feature like Allocator that could be mimalloc or jemalloc (both already provided by vcpkg) Also a bunch of otrher features that wouzld correspond to HPX Build Settings'
<Yorlik> Oh that ...
<Yorlik> Honestly - I'm not sure if it is really the best solution.
<Yorlik> Because HPX has so many option it would require a crazy large feature vector
<Yorlik> it is most likely the most viable way to just clone the vanilla port and modify it
<Yorlik> I can make a short tutorial for that - it's really simple.
<hkaiser> I have no idea how to add optional settings to the port file
<Yorlik> I made a port that always uses mimalloc
<Yorlik> Simply add mimalloc in the control file to the dependencies and add the hpx allocator variable in the portfile.cmake
<Yorlik> the call vcpkg with the --overlay-ports option
<Yorlik> I'll make a writeup
* Yorlik adds it to the todo list
bita has quit [Ping timeout: 260 seconds]
<K-ballo> this is not quite right yet, but already pretty scary https://github.com/K-ballo/hpx/commit/f391e86d392dbdfcd64aab2ea18adcf07fa2379e
<Yorlik> hkaiser: Made a very simple example for a custom hpx port (e.g. to use mimalloc) here: https://mckillroy.github.io/hpx_snippets/vcpkg_custom_hpx_port.html
<hkaiser> K-ballo: why scary?
<hkaiser> and why did you switch to #include "" syntax?
<K-ballo> I didn't, that's iwyu internal policy... <> is only for stuff found via system includes
<K-ballo> I'm doing a new run with a modified database to get <>
<K-ballo> scary: ~2,204 missing includes; ~1,142 extra includes
<hkaiser> Yorlik: sure, that I understand - what I thought was that you'd know how to add options to the standard port file, vcpkg supports that using the hpx[option]:x64-windows triplet syntax
<hkaiser> K-ballo: that's scary indeed
<Yorlik> hkaiser: It's not hard - they have a function to check options - question is if it is really viable.
<hkaiser> Yorlik: why not?
<Yorlik> Considering how many options there are in the HPX build
<hkaiser> you could just say hpx[mimalloc]:...
<Yorlik> Allocator just being one of so many.
<Yorlik> Sure. But where would you stop?
<hkaiser> well, the most important ones would make sense
<Yorlik> I saw how they did it in the Lua püort
<Yorlik> Give me a list and I can look at it
<Yorlik> It's not tricky
<hkaiser> K-ballo: does it add the includes itself?
<K-ballo> there's another tool that parses the output and modifies the sources
<hkaiser> ahh
<hkaiser> K-ballo: so it selects the lowest level #include needed for a particular feature?
<K-ballo> uhm, not really.. there are mappings
<hkaiser> K-ballo: and that needs to be created manually, obviously
<hkaiser> sounds like a lot of work
<K-ballo> there's an heuristic that works for "normal" use cases
<K-ballo> I only manually mapped compatibility and global headers
<hkaiser> ok
<hkaiser> nod, ok
<K-ballo> some odd stuff will probably need to be manually mapped, for sure
<K-ballo> also iwyu doesn't seem to recognize our layout with separate headers and sources with different hierarchies, so for best results one would have to map all .cpp files to their .hpp correspondents, but I don't think it's worth the trouble
bita has joined #ste||ar