CMake: add support for -lrt if needed? about slim

[molpopgen]

Yeah, that's the way to do it.

[brnorris03]

Here is what has worked for me for a number of years on many platforms, in case it helps. This gives you milliseconds.

#include <chrono>

auto start = std::chrono::steady_clock::now(); // start timer
// do some work
auto end = std::chrono::steady_clock::now();
auto diff = end - start;
std::cout << "Elapsed time: " << std::chrono::duration <double, std::milli> (diff).count() << " ms" << std::endl;

[jeromekelleher]

Looks like this worked @bhaller, no problem with the conda build on this tarball.

To get a working conda version out the best option would be to push out a point release on github. I'm in no hurry with this though, it's entirely up to your schedule. It would be nice to resolve the external GSL thing too (#66) also for packaging.

[jeromekelleher]

Note from @molpopgen:

@bhaller -- you may want to try to include ctime.h instead of time.h so that you use std::time instead of time as the function call. Ideally, the build system would allow one to check for the existence of functions in different headers, but that is easier with autools than with cmake.

[molpopgen]

I did mess that up! <ctime> not <ctime.h>.

…

On Fri, Jan 17, 2020, 8:39 AM Jerome Kelleher ***@***.***> wrote: Note from @molpopgen <https://github.com/molpopgen>: @bhaller <https://github.com/bhaller> -- you may want to try to include ctime.h instead of time.h so that you use std::time instead of time as the function call. Ideally, the build system would allow one to check for the existence of functions in different headers, but that is easier with autools than with cmake. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#67?email_source=notifications&email_token=ABQ6OHY6RH2LQAK4SGSCWSTQ6HNC3A5CNFSM4KIK6F52YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJIH5IA#issuecomment-575700640>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABQ6OH75WVEHO5YPYWSJJFDQ6HNC3ANCNFSM4KIK6F5Q> .

[bhaller]

I have just committed a switch from "time.h" to . I get no warnings when building with this header change, despite having made no other code changes, on my own machine or on Travis-CI, but I won't be surprised if there are, as @molpopgen said, some spots where I have to switch to using a std:: time function instead; on some platforms the C-style functions automatically get set up to be pass-throughs to the std:: functions by the corresponding C++ header (which I think is perhaps the way it is supposed to be?), on other platforms they don't. So there might be a bit of shaking out yet to happen. But modulo that, perhaps this resolves the glibc issue, without having to add -lrt. I'm not sure how to re-run @jeromekelleher 's conda-forge PR, but maybe it should now work, if using the newly committed SLiM?

[molpopgen]

I'm only appreciating now that the problem was at link-time and not at compile time. (My head has been in C++ template land too long...).

If you want to avoid linking to lrt, you may consider using the C++11 <chrono> types? These may avoid the link-time issue as they are implemented as templates. I just read thru the GCC7 implementation, which is the current conda compiler version, and std::high_resolution_clock doesn't make use of the C function with the missing symbol. In fact, it isn't referred to at all in the header on my system.

[bhaller]

If you want to avoid linking to lrt, you may consider using the C++11 <chrono> types?

I did investigate those, and couldn't get them to work. I don't recall what the problem was, but I beat my head against the wall for a while and gave up.

Apropos of my previous comment: it turns out that commenting out all the includes for ctime doesn't even affect the build, on my machine; some other header must be including time.h or ctime, making my includes redundant (at least on my own machine; of course that might be different on a different machine). So I think the change I committed is unlikely to fix the problem in question, at least not reliably. Sorry, quite distracted over here as I'm teaching a workshop right now.

[bhaller]

Looking at steady_clock now, I think perhaps I recall my frustration. I want to implement an Eidos function that returns a monotonic clock time to the user as a float. But steady_clock::now() gives you a steady_clock::time_point, which I could find no way of converting into a number that I could return to the user. It occurs to me now, however, that I can perhaps just take a time-base with now() at launch, and then calculate durations relative to that time-base, perhaps giving me the numeric clock values I want. Then I have to convert those durations into seconds, and that ought to be what I want. I'll work on that, in between workshop queries. :->

[bhaller]

OK, I have now made a less obviously pointless commit. :-> I've moved over to C++ for clock() (now std::clock()), and have switched to std::chrono for the monotonic clock stuff. I think the -lrt linkage should no longer be necessary, maybe. @jeromekelleher , want to try it out?

[molpopgen]

This should solve #63, too, right?

[bhaller]

This should solve #63, too, right?

That's the hope. I'm just waiting for confirmation that it does what I'm hoping, in the context of the conda-forge build, before I close this and #63.

[jeromekelleher]

The updates sounds great. To try this out here, the simplest thing is to make a tarball of the code and put it on a webserver somewhere. I can edit the URL in the recipe to point to this new tarball just to see if it works.

[jeromekelleher]

Sorry, by "here" I meant in the conda-forge PR.

[bhaller]

Hi @jeromekelleher. OK, I have uploaded a tarball of the sources to http://www.benhaller.com/slim/SLiM_conda_test.tar. Thanks! By the way (you also might care @petrelharp), I will be incommunicado for the next several days – laptop is going in for repairs, and for some reason my email only fetches properly if my laptop fetches it, so.

[jeromekelleher]

I tried this in conda-forge/staged-recipes#10613 @bhaller, but the tarball doesn't have the right structure (it has full file system paths from your system). Can you make one that looks like the gzipped tarballs that are used on the GitHub releases page please?

[bhaller]

OK, I just put up a new one that looks the same to me; give that a try. (Same URL as before.) Thanks!

[jeromekelleher]

Still not working I'm afraid. There's a lot of extra stuff in there and the root directory name is different. Also probably best to gzip it.

[bhaller]

Ah, didn't realize the root directory name had to match exactly; so it should be SLiM-3.3.1? I have made that change. The extra stuff is macOS cruft; I think I have now excluded it. I have also gzipped it. The URL is now http://www.benhaller.com/slim/SLiM-3.3.1.tar.gz to match the GitHub filename for the current SLiM release. Hopefully this does the trick! Thanks!

[bhaller]

Awesome, thanks a bunch for doing this legwork @jeromekelleher. I'm not sure when I'll want to do a new release; I'll think about that. Perhaps soon, just to get this rolling. I think @brnorris03 might have the GSL issue on her radar.

[bhaller]

I'll mark this as closed since the other things mentioned are represented by separate issues. Note this fixes #63 also.