## Where communities thrive

• Join over 1.5M+ people
• Join over 100K+ communities
• Free without limits
##### Activity
Eyal Rozenberg
@eyalroz
The open issues on my repo are simply due to autoclose not working on branches other than the main one.
Eyal Rozenberg
@eyalroz
Now, about those CMakeLists changes... let me summarize them:
1. Need to use CMake's internal CUDA support - available only since CMake 3.8 . I trust that's not a problem w.r.t. the systems you target?
2. For the statically-compiled version of the library, the CUDA-device-side code also needs to be compiled (and "device-side linked"). This necessitates the strf-cuda static library - an added target.
3. The install locations you used are non-standard. Actually, I need to be even more customs-and-standards compliant and use GNUInstallDirs for better multiplatform support. See: https://www.youtube.com/watch?v=m0DwB4OvDXk (26:30) . So, do expect another small commit before merging to standardize the install paths.
4. There's a standard naming scheme for package config files and version-specific config files. See the same talk at around 22:30. As for the exact location of the my-package-name-config.cmakefile - there are several options, but install directory root and then a cmake/ subdir is not one of them... it's mostly either share/cmake/ or share/cmake/my-package-name or lib/cmake/ or lib/cmake/my-package-name, if memory serves me correctly.
Eyal Rozenberg
@eyalroz
by the way - if you decide to introduce a version number at some point, there are conventions regarding how to reflect that in the CMake installation :-(
robhz786
@robhz786
I'm not very knowledgable with CMake practice. So that video will be valuable to me.
Eyal Rozenberg
@eyalroz
If that's the case, that might not be the thing you want to watch first
robhz786
@robhz786
This message was deleted
I get some errors when running CMake in a computer that doesn't have NVCC . I think I will create a CMake option variable STRF_CUDA, so that the CUDA stuff are only enabled when the variable is ON.
Also, most users won't use strf on CUDA, so it makes sense to make it optional
Eyal Rozenberg
@eyalroz
Yes, that makes sense, certainly.
I think I might bundle that up with the rest of the CMake stuff I'm tweaking right now.
Eyal Rozenberg
@eyalroz
Ok, pushed another commit (and amended a previous commit message).
Please have a look at the CMakeLists.txt now (or after watching Pfeiffer's talk).
Eyal Rozenberg
@eyalroz
... and I push -f'ed it again now.
robhz786
@robhz786
merged into develop
Eyal Rozenberg
@eyalroz
Looks like the Travis build is failing. ... I don't think we changed the travis YAML file to install the CUDA package.
Oh wait, that's not the problem.
There's some issue with clang-3.8 .
home/travis/build/robhz786/strf/test/utf_to_utf.cpp:99:11: error: suggest braces around initialization of subobject [-Werror,-Wmissing-braces]

{ pair{3, "\xF1\x80\x80\xE1\x80\xC0"} // sample from Tabble 3-8 of Unicode standard

^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Also...
what is the procedure/criteria/schedule for the contents of the develop branch making it to the master branch?
robhz786
@robhz786
The master branch is for releases. So I commit into master only when changing the version number. And the criteria of changing the version is a little sax now, since the version is still < 1.0
Eyal Rozenberg
@eyalroz
So what is the lax criterion for bumping the version number?
... when you bump it, I'll be able to have my cuda-kat library depend on that strf version minimum; for now it's a bit of a "broken" dependence, in the sense that only your develop branch would work but I'm not trying to detect that.
By the way...
That's not covering everything - e.g. standard prefix generators for different printing resolutions - but it covers a bunch of stuff.
Haven't implemented a sprintf()yet, will do that at some point later on with C-style varargs and a stringstream.
robhz786
@robhz786
I'm just trying to fix that issues on appveyor, then I think I will release it into master
robhz786
@robhz786
About that CMake variable you created - STRF_BUILD_CUDA_STATIC_LIB. What if we renamed to just STRF_CUDA? After all, it also activates the unit-tests that use the header-only library.
Eyal Rozenberg
@eyalroz
Hmmm. We could do that (but I'd use the name STRF_CUDA_SUPPORT). We could alternatively always enable the header-only CUDA unit tests if CUDA is detected...
But here's an idea: Have a STRF_CUDA_SUPPORT variable, but also have a STRF_BUILD_STATIC_LIBRARY variable, defaulting to true. When The second one is false, we only run header-only tests and don't build anything except examples and perf tests. That means that, theoretically, strf could be made and installed without compiling anything.
Although that doesn't really depend on whether CUDA is supported or not, so never mind.
Let's just go with STRF_CUDA_SUPPORT for now.
robhz786
@robhz786
Released version 0.10.2 on master
Eyal Rozenberg
@eyalroz
Awesome!
... but perhaps you could mention, on the release notification, what are the main changes in the release?
(Yes, I know you haven't done this for previous releases, but I think it is important, even if it's just two or three lines.)
robhz786
@robhz786
You mean in the tag messages ?
Eyal Rozenberg
@eyalroz
The tag message is fine. Just FYI, I think GitHub also lets you write something extra for the releases page.
Eyal Rozenberg
@eyalroz
Your release doesn't actually have a version set (neither in any header AFAICT nor using CMake). Or - did I miss it?
robhz786
@robhz786
robhz786
@robhz786
Version 0.11 Released.
There are many breaking changes. But I expect them to be the last ones before version 1.0.
Eyal Rozenberg
@eyalroz
I'll have a look. Thanks for the heads up :-)
Eyal Rozenberg
@eyalroz
Roberto?
If you're around - I would appreciate some guidance about the changes over the past half-year or so.
Eyal Rozenberg
@eyalroz
... never mind, I think I managed. But still - please make 0.10.4 available again.