nikunj has quit [Remote host closed the connection]
<simbergm>
Yorlik: layout=system probably helps
<simbergm>
I don't know if it's hpxs, cmakes, or boosts fault, but starting from boost 1.69 or 70 they changed what they stick at the end of libraries in the tagged (I think?) layout which isn't recognized by cmake/hpx
<Yorlik>
simbergm: Thanks - I had used versioned - trying now ...
<simbergm>
yeah, that should also work
<simbergm>
just not whichever one you used to get that long one
<Yorlik>
That was versioned
<simbergm>
to early... I read you're trying versioned now
<simbergm>
then system should help you
<simbergm>
*too
<Yorlik>
Yes - I'm switching from versioned to system now
daissgr_work has quit [Ping timeout: 244 seconds]
daissgr has joined #ste||ar
daissgr_ has joined #ste||ar
daissgr_ has quit [Read error: Connection reset by peer]
<Yorlik>
It's not building with clang and system layout
<Yorlik>
Have to say this management of boost and HPX builds is the single most royal pain in the assets in my entire project.
<simbergm>
Yorlik: debug/release in the same build?
<Yorlik>
No - just debug
rori has joined #ste||ar
<simbergm>
Yorlik: what happened then?
<Yorlik>
I am building again to make sure there are no weird interactions with previous builds
<Yorlik>
I am not sure i understand the problem fully yet.
* Yorlik
is working on it
<Yorlik>
I have a strange feeling something might be weird inside the boost build system.
<Yorlik>
Yup - the clang build using toolset=clang-win fails miserably with clang8 on windows
<Yorlik>
using minimal and system
<Yorlik>
I think I'll have to give up on building Boost&HPX with Clang8 on Windows. This is just taking too much time and hassle. But it kinda sucks, since for the real thing we will need Clang, on Linux though, and that works. I just wanted to keep it cross platform and that is quite hampered..
<Yorlik>
It's the output from my cmake file listing the arguments we give to b2
<zao>
Straying outside of the blessed box, I don't envy you :)
<zao>
It's somewhat likely that it's FindBoost.cmake that might not be up to snuff.
<Yorlik>
The problem it poses on me is simply that I will have to go to Linux and compile there much more often now.
<Yorlik>
I had just fixed my stuff, since I had done most development on Windows and Linux popped up a bunch of -mostly miniscule- errors.
<Yorlik>
So - I'd really prefer to use one compiler on both OSes
<Yorlik>
And it should be clang :)
<Yorlik>
Seems I have give up that idea
<Yorlik>
At least remot development with VSCODE over SSH works nicely
<zao>
Including security holes :)
<zao>
The current remote server (until recently at least) listens on all interfaces.
<zao>
They're slowly working to constrain it down to just listening on localhost, but that's not good enough unless they also have some token-based security.
<zao>
Couldn't find out if they have any auth yet, as the only server source available is in minified JS, so essentially worse than Perl.
<Yorlik>
Oh - remote means my local VM :)
<zao>
Good enough then.
<zao>
Remote for me means compute clusters on public IPv4 and IPv6 without firewalls :D
<Yorlik>
Sure.
<Yorlik>
Is it not even restricted to SSH? Thats really ... meh ..
<Yorlik>
BTW - All servers I used in the last years didn't have any iptables or anything.
<Yorlik>
What you don't expose can't be exploited ...
<zao>
Yorlik: It does the initial setup and new connections via SSH into the machine, where it forwards traffic to a node.js bullshit server listening on wildcard.
<Yorlik>
lol - thats nuts
<zao>
So all traffic between your client and the server is encapsulated in SSH forwards, but the actual server is reachable by kreti and pleti.
<Yorlik>
netcat and curl ftw
<Yorlik>
Thanks for the heads-up on this!
<zao>
Only poked a bit at the open port, it speaks some sort of REST API over HTTP.