aserio 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/
EverYoung has quit [Ping timeout: 276 seconds]
EverYoun_ has quit [Ping timeout: 276 seconds]
EverYoung has joined #ste||ar
EverYoun_ has joined #ste||ar
EverYoun_ has quit [Remote host closed the connection]
EverYoun_ has joined #ste||ar
EverYoung has quit [Ping timeout: 240 seconds]
jakub_golinowski has quit [Ping timeout: 240 seconds]
EverYoung has joined #ste||ar
EverYou__ has joined #ste||ar
EverYou__ has quit [Remote host closed the connection]
EverYoung has quit [Read error: Connection reset by peer]
EverYoung has joined #ste||ar
EverYoun_ has quit [Ping timeout: 240 seconds]
EverYoung has quit [Ping timeout: 265 seconds]
EverYoung has joined #ste||ar
EverYoung has quit [Remote host closed the connection]
EverYoung has joined #ste||ar
EverYoung has quit [Remote host closed the connection]
EverYoung has joined #ste||ar
EverYoung has quit [Ping timeout: 245 seconds]
vamatya has joined #ste||ar
EverYoung has joined #ste||ar
<parsa[w]>
hkaiser: i'm done with refactoring the primitives... all of them are updated, except random which you asked not to touch
EverYoung has quit [Remote host closed the connection]
mcopik has joined #ste||ar
mcopik has quit [Client Quit]
K-ballo has quit [Quit: K-ballo]
<hkaiser>
parsa[w]: ok, thanks a lot!
parsa has joined #ste||ar
EverYoung has joined #ste||ar
diehlpk has joined #ste||ar
EverYoung has quit [Ping timeout: 245 seconds]
hkaiser has quit [Quit: bye]
anushi has joined #ste||ar
anushi has left #ste||ar [#ste||ar]
anushi has joined #ste||ar
Anushi1998 has quit [Ping timeout: 245 seconds]
diehlpk has quit [Ping timeout: 245 seconds]
anushi has quit [Remote host closed the connection]
anushi has joined #ste||ar
Anushi1998 has joined #ste||ar
anushi has quit [Ping timeout: 265 seconds]
Anushi1998 has quit [Remote host closed the connection]
<jakub_golinowski>
Good morning, I have a question regarding building the HPX. In the documentation it is recommended to build recent version of Boost from sources. What is more it is recommended to use the build-type=complete while executing ./b2
<jakub_golinowski>
I followed all this steps and succesfully build the boost in the directory of my choice. To ensusre it is working I built an executed example cpp programs using boost.
<jakub_golinowski>
After building hwloc I proceeded to building hpx. I forgot to mention that my platform is Ubuntu 16.04
<jakub_golinowski>
When runnig cmake as advised in the documentation of hpx I encounter an issue. Due to the fact that the library names are versioned (which was requested when I wanted to use build-type=complete while building boost) cmake is unable to find libraries in /lib directory
<jakub_golinowski>
Example:
<jakub_golinowski>
(part of debug output from cmake)
<jakub_golinowski>
-- [ /usr/share/cmake-3.5/Modules/FindBoost.cmake:1404 ] Searching for CHRONO_LIBRARY_RELEASE: boost_chrono-gcc54-mt-1_66;boost_chrono-gcc54-mt;boost_chrono-mt-1_66;boost_chrono-mt;boost_chrono
<jakub_golinowski>
So my Question is: why do we need to use build-type=complete while building boost for HPX? And is there another argument I can pass to the cmake to solve this issue?
<jakub_golinowski>
I encountered the Issue on cmake gitlab but it is still open
<zao>
They must've changed the semantics of "complete" since I last used it. Thought that Linux builds defaulted to --layout=system.
<zao>
Is it full --layout=versioned, or just --layout=tagged?
<zao>
tbh, I just build a default Boost with the only change being cxxflags and toolset. Didn't notice any recommendations to go "complete".
vamatya_ has quit [Ping timeout: 248 seconds]
<zao>
jakub_golinowski: I believe the problem is that Boost apparently has architecture in the library filename nowadays.
<zao>
That's a very new invention, I've never seen it before.
<zao>
(back in the days when I argued for it they were violently against it)
Smasher has quit [Remote host closed the connection]
Smasher has joined #ste||ar
quaz0rus has joined #ste||ar
quaz0r has quit [Ping timeout: 256 seconds]
quaz0rus is now known as quaz0r
nikunj has joined #ste||ar
EverYoung has joined #ste||ar
<heller_>
nikunj: the paths are hard coded. They don't exist where it's looking for it
EverYoung has quit [Ping timeout: 255 seconds]
<nikunj>
@heller_: oh, that's why! What should I do in this case then?
<heller_>
Only run it within the docker image?
<heller_>
That should be enough
<nikunj>
@heller_: Ok, I'll confirm with @hkaiser ( he wished to have it done using cmakelists that mimicks hello.sh commands ) and then apply the same.
<heller_>
Sure
<heller_>
That's the same thing. Cmake is run within docker
parsa has joined #ste||ar
<nikunj>
@heller_: I see. Then I'll keep a cmakelists in case user wishes to build the example, while add docker commands to build and run it in circle
quaz0r has quit [Quit: WeeChat 2.1-dev]
nikunj has quit [Ping timeout: 260 seconds]
Smasher has quit [Remote host closed the connection]
Smasher has joined #ste||ar
K-ballo has joined #ste||ar
parsa has quit [Quit: Zzzzzzzzzzzz]
parsa has joined #ste||ar
hkaiser has joined #ste||ar
CaptainRubik has joined #ste||ar
EverYoung has joined #ste||ar
EverYoung has quit [Ping timeout: 276 seconds]
CaptainRubik has quit [Ping timeout: 260 seconds]
<jakub_golinowski>
zao: Yes in fact linux defaults to --layout=system however when you use option build-type=complete then it says that system is no longer possible and one has to choose either versioned or taggeg. I think I went for versioned
<parsa>
hkaiser: ping
CaptainRubik has joined #ste||ar
vamatya_ has joined #ste||ar
CaptainRubik has quit [Ping timeout: 260 seconds]
<zao>
Neato... ttd.exe can do command line captures for time-travel debugging.
Smasher has quit [Read error: Connection reset by peer]
Smasher has joined #ste||ar
<hkaiser>
parsa: here now
<parsa>
hkaiser: can we have a separate repository for phylanx's build environment image? our current docker image is built every time which is unnecessary… and it only contains the build prerequisites not phylanx itself
<hkaiser>
parsa: we should change our circleci system to rely on a docker image that has all the prerequisites installed
<parsa>
i'm experimenting with that right now
<hkaiser>
that might involve changing the base image that is used for hpx, though
<parsa>
why?
<hkaiser>
why not?
<parsa>
because there's no need for to change the hpx image we use
<hkaiser>
phylanx has to be built using the latest successful hpx build on circleci
<hkaiser>
(it currently uses that)
<parsa>
is what we use currently not the most updated hpx?
<parsa>
recent*
<hkaiser>
we currently use the latest successful hpx build from circleci
<hkaiser>
that's why we have to add prerequisites to build phylanx
<parsa>
yeah, i'm asking if we can have a separate stellar-group repo for that image so i can set it up?
<hkaiser>
parsa: how do you plan to do that?
<hkaiser>
you have to built it for every hpx build
<parsa>
github sends a ping to docker (from HPX repo), triggers a build
<hkaiser>
wel, you should use the latest sucessful hpx build, hpx master might be broken after all
<parsa>
well yeah that'd be a problem
<hkaiser>
parsa: we currently upload the docker image from the hpx circleci master nbuilder if the build was successful, this is then used for the phylanx builds
<heller_>
what prereqs are missing in the base image?
<heller_>
note that you can compose more than one base image
<hkaiser>
heller_: mainly pybind11 and HighFive/HDF5
<hkaiser>
needed for the phylanx build, currently we install those for every build which is annoying
<hkaiser>
ahh yes, and python
<heller_>
yeah, you can create a docker image with those
<heller_>
and add it in the phylanx build
<hkaiser>
the phylanx build uses the hpx image for its base
<heller_>
look at docker-compose
parsa has quit [Quit: Zzzzzzzzzzzz]
nikunj has joined #ste||ar
vamatya_ has quit [Ping timeout: 240 seconds]
<nikunj>
@hkaiser: Regarding the hello_world_component, I talked to @heller_ and he asked me to run the build commands directly in circleci rather than running it through cmake since the paths are hard coded. That was the primary reason why my builds did not compile in circle.
<heller_>
I told you, not asked you ;)
<heller_>
and I didn't say you should not run in directly in cmake
<nikunj>
@heller_: Oh so it seems like I misunderstood a bit
<nikunj>
@heller_: How can I run it directly from cmake in that case?
<nikunj>
@heller_: Apologies for misunderstanding :(
<heller_>
what do you want to achieve?
<nikunj>
@heller_: Keep a cmakelists so that a user can build in case he/she wishes to. At the same time that cmake can be runned inside circle to check if the example is built correctly
<nikunj>
@heller_: Also that cmakelists is supposed to check for linux only built since it basically invokes commands inside of hello.sh file inside hello_world_component folder
<heller_>
so, making sure the code builds in the first place, should be good enough ... the external build system support is tested in other unit tests