<hkaiser>
right, phylanx_setup_target is supposed to do the same
<hkaiser>
the strip?
<simbergm>
since HPX_LINKER_FLAGS was empty all the linker flags that hpx_wrap and hpx_setup_target set before that get reset
<nikunj>
phylanx_setup_target make use of exported variables which broke a while ago. I make use of hpx_setup_target and removed the setupHPX script itself
<simbergm>
nikunj thanks!
<nikunj>
I do a find_package hpx to let cmake locate hpx and then use the exposed hpx_setup_target to build the executables and libraries
<hkaiser>
ok, sounds good
<hkaiser>
thanks
<nikunj>
should I add another pr or add a commit to that branch itself?
<hkaiser>
nikunj: could you do a PR for this, please?
<nikunj>
let's see if things work on the container as well
<hkaiser>
yah, add it to the branch
<hkaiser>
(forgot there was a PR already)
<zao>
Does that work with all supported ways of finding HPX or just one? (HPX_DIR vs. CMAKE_PREFIX_PATH)
<zao>
If both are still valid, of course. Always seems a bit hit-and-miss with CMake :)
<hkaiser>
zao: I didn't even know you could use the CMAKE_PREFIX_PATH to detect things
<simbergm>
zao: this doesn't affect that, those variables just tell cmake where to look and we can't really break those even if we tried
<hkaiser>
I thought that was the target installation path for a library
<nikunj>
hkaiser: I don't have permissions to phylanx
<zao>
hkaiser: that’s supposed to be the universal way to specify where deps live, unless the CMake folks have changed their minds lately
<hkaiser>
nikunj: sec
<zao>
That’s cmake_install_prefix
<hkaiser>
ahh right
<zao>
I also always mix their spelling up :)
bibek has quit [Quit: Konversation terminated!]
<zao>
simbergm: alright, you never know how clever you people are :)
bibek has joined #ste||ar
<hkaiser>
nikunj: you should have received an invitation for that repo
<nikunj>
hkaiser: let me check
<nikunj>
hkaiser: got it. Thanks!
<simbergm>
zao: true :P
<nikunj>
hkaiser: added to the PR, let's hope it fixes things
bibek has quit [Quit: Konversation terminated!]
bibek has joined #ste||ar
<hkaiser>
thanks nikunj
hkaiser has quit [Quit: bye]
aserio has joined #ste||ar
bibek has quit [Quit: Konversation terminated!]
bibek has joined #ste||ar
bibek has quit [Client Quit]
bibek has joined #ste||ar
bibek has quit [Client Quit]
hkaiser has joined #ste||ar
weilewei has joined #ste||ar
<simbergm>
hkaiser: do you have more comments on #4142 and #4147?
<hkaiser>
simbergm: have not looked at #4147 yet, I'll get back to you on those by Monday - would that be ok?
<simbergm>
hkaiser: yes, no problem at all
<simbergm>
thanks!
<hkaiser>
simbergm: if I want to reference a file from inside a module's documentation using a relative path, what would be the base directory?
<simbergm>
hkaiser: hmm, what sort of file would you like to reference? source files or other rst files (from same module, different module, base docs?)?
<hkaiser>
a source file to extract some code from a test in the same module
<simbergm>
sec
<simbergm>
hkaiser: you'd need to add a symlink for that
<simbergm>
so includes are either relative to ${CMAKE_BUILD_DIR}/docs/sphinx with no leading slash
<simbergm>
or relative to the current file
<hkaiser>
ok, thanks!
<simbergm>
but the docs files get copied over to the build directory, so it would be relative to that
<hkaiser>
so relative to the current rst file would be fine, still?
<hkaiser>
simbergm: also, do I need to list module files somewhre in order for the doxygen comments to be extracted?
<simbergm>
and then you'd need the somewhat ugly relative path from ${CMAKE_BUILD_DIR}/docs/sphinx/libs/<module_name>/docs/index.rst to ${CMAKE_BUILD_DIR}/docs/libs/<module_name>/examples/myfile.cpp
<simbergm>
hkaiser: no, all files in modules are doxygenated, unlike in the main library where we have the explicit list
<hkaiser>
k
<hkaiser>
thanks
<simbergm>
not sure how to handle those relative paths in a cleaner way...
<heller>
hkaiser: are you planning to be in belfast?
<hkaiser>
heller: no :/
<heller>
Ok
<heller>
Let's hope they don't need everything up
<heller>
mess*
<hkaiser>
eternal hope...
<heller>
There's talk about getting P0443 in for 20
<heller>
Which would be a desaster
<hkaiser>
heh
<hkaiser>
if you know why it's a disaster, write a paper
<heller>
Too late
<heller>
I told Eric that I'll be sending him comments
<hkaiser>
simbergm: can examples or tests in modules depend on the components?
<hkaiser>
e.g. iostreams?
<hkaiser>
heller: never too late
<hkaiser>
if you can convince Bryce that you have a point he can raise some ruckus
<heller>
Well, Eric knows that it's not ready yet
<heller>
Let's see, I want to get the implementation of it first
<hkaiser>
right
<K-ballo>
there's no chance of getting P0443 in 20
<simbergm>
hkaiser: yes, they can, but I don't remember now if they need some fiddling with the names
<simbergm>
because we rewrite component names based on if there's a target, if it has an hpx_ prefix etc.
maxwellr96 has joined #ste||ar
<simbergm>
I think it works just normally
<hkaiser>
simbergm: looks like that the targets do not exist yet when modules are processed, but I'm not sure
<hkaiser>
no, it doesn't work :/
<simbergm>
hkaiser: right, can you try setting DEPENDENCIES iostreams_component instead of COMPONENT_DEPENDENCIES iostreams?
<hkaiser>
will try
<heller>
K-ballo: yes, the question came up regarding dependencies on coroutines and the possibility of adding executors to 20, if I'm not mistaken
<K-ballo>
there's no chance of adding executors to 20
<heller>
I hope so
<weilewei>
Does hpx support cuda aware mpi? Let's say, I have an cuda allocated array on node 0, then send it directly to node 1 using NVlink?
<weilewei>
During this process, cpu is not involved
<nikunj>
hkaiser, simbergm: looks like my fix has passed the ci as well. I guess my work here is done then. I'll get back with rtohid_'s work now.