[ANN] sbbdep 0.3.2

source for sbbdep 0.3.2 is available
also submitted the update to SBo so it should be on the weekend available
and therefore binary packages shortly later via SlackOnly

maybe already before next weekend via AlienBob's repo?
http://www.slackware.com/~alien/slackbuilds/sbbdep/


changes:
does resolve the link if the directory for the cache db (XDG_CACHE_HOME) is a link to an other directory.
Thanks Hunter for the bug report


if you do not now what sbbdep is:
https://bitbucket.org/a4z/sbbdep/wiki/Home

feature request and bug reports here, via the bitbucket issue tracker or simply via mail to me


apropos features, @Didier
I have evaluated if I should use a different directory for the cache, but I think XDG_CACHE_HOME is exactly correct. This is not data sbbdep needs, it will create it on the fly if it's not available and store it as cache for speed up future operations. So an other XDG dir seems not that suitable, I think.

The 0.3.2 release seems to be working for me, thanks!

Working great here, really helpful. I did have to add -pthread to CXXFLAGS to get the compile to work.

Originally Posted by chrisretusn Working great here, really helpful. I did have to add -pthread to CXXFLAGS to get the compile to work.

you build it yourself, from source?

this should not be required and I think this happens only if you provide custom CMAKE_CXX_FLAGS, what you should not do
user settings should be set via CMAKE_CXX_FLAGS_RELEASE, if you build a release config

please have a look at the slack build file
http://slackbuilds.org/slackbuilds/1...dep.SlackBuild
to see how to apply custom compiler flags, without erasing those flags the developer thinks are required
in case of sbbdep this is:
"-Wall -Wextra -pedantic -std=c++14 -pipe -pthread"
everything else can be set by the user via the DCMAKE_CXX_FLAGS_${BUILD_CONFIGURATION}, if nothing is given very good defaults will be used

Originally Posted by a4z you build it yourself, from source?

Yes, custom SlackBuild.

this should not be required and I think this happens only if you provide custom CMAKE_CXX_FLAGS, what you should not do user settings should be set via CMAKE_CXX_FLAGS_RELEASE, if you build a release config please have a look at the slack build file http://slackbuilds.org/slackbuilds/1...dep.SlackBuild to see how to apply custom compiler flags, without erasing those flags the developer thinks are required in case of sbbdep this is: "-Wall -Wextra -pedantic -std=c++14 -pipe -pthread" everything else can be set by the user via the DCMAKE_CXX_FLAGS_${BUILD_CONFIGURATION}, if nothing is given very good defaults will be used

This is my cmake config in my SlackBuild. I do add the standard flags before this process, in this case for x86_64 "-O2 -fPIC" same as the SBo SlackBuild.

cmake .. \
  -DCMAKE_C_FLAGS:STRING="$SLKCFLAGS" \
  -DCMAKE_CXX_FLAGS:STRING="$SLKCFLAGS -pthread" \
  -DCMAKE_INSTALL_PREFIX=/usr \
  -DCMAKE_INSTALL_MANDIR=/usr/man \
  -DCMAKE_BUILD_TYPE=Release \
  -DUSE_INTERNAL_SQLITE3=OFF \
  -DCMAKE_DOC_DIR=doc/${PKGNAM}-${VERSION} \
  2>&1 | tee $OUTPUT/cmake-$PKGNAM.log || exit 1

I changed this "FLAGS" options to match the SBo SlackBuild.

cmake .. \
  -DCMAKE_C_FLAGS_RELEASE:STRING="${SLKCFLAGS}" \
  -DCMAKE_CXX_FLAGS_RELEASE:STRING="${SLKCFLAGS}" \
  -DCMAKE_INSTALL_PREFIX=/usr \
  -DCMAKE_INSTALL_MANDIR=/usr/man \
  -DCMAKE_BUILD_TYPE=Release \
  -DUSE_INTERNAL_SQLITE3=OFF \
  -DCMAKE_DOC_DIR=doc/${PKGNAM}-${VERSION} \
  2>&1 | tee $OUTPUT/cmake-$PKGNAM.log || exit 1

The compile succeeds, but in the output of the configure I get the following:

CMake Warning:
  Manually-specified variables were not used by the project:

    CMAKE_C_FLAGS_RELEASE

I don't get the same warning with my original configure options. I noticed that C_FLAG is probably not needed. That said, my original was not passing any of your compile flags (VERBOSE=1). Those two options in my original are quite common in other SlackBuilds. The current SBo cmake.template.SlackBuild uses them. I made my own template to create my SlackBuilds, the cmake section of my template is listed below. This is my starting point, adjusted as needed. Most of these I gathered from experience and the cmake files. Looks like I will be adding to the list. I have to wonder now if none of the author intended flags have been passed in my scripts that use cmake. I don't pay much attention to that unless a compile fails. I plan to go back and check a few programs to see. They are working fine though.

cmake .. \
  -DCMAKE_C_FLAGS:STRING="$SLKCFLAGS" \
  -DCMAKE_CXX_FLAGS:STRING="$SLKCFLAGS" \
  -DCMAKE_INSTALL_PREFIX=/usr \
  -DCMAKE_INSTALL_SYSCONFDIR=/etc \
  -DCMAKE_INSTALL_LIBDIR=lib$LIBDIRSUFFIX \
  -DCMAKE_INSTALL_DOCDIR=/usr/doc/$PKGNAM-$VERSION \
  -DCMAKE_INSTALL_MANDIR=/usr/man \
  -DLOCALSTATEDIR=/var \
  -DBUILD_SHARED_LIBS=on \
  -DCMAKE_BUILD_TYPE=Release \

Thanks for taking the time to reply. Always learning things, that why I decided to build my own and one reason I use Slackware.

I can also reproduce the cmake warning.

CMake Warning:
  Manually-specified variables were not used by the project:

    CMAKE_C_FLAGS_RELEASE

When using a system version of sqlite3, but not the internal version.

My suggestion is to get rid of 'CMAKE_CXX_FLAGS_${BUILD_CONFIGURATION}' and only use 'CMAKE_CXX_FLAGS' which is standard in pretty much every cmake build. See the cmake template for an example.

http://slackbuilds.org/templates/cma...ate.SlackBuild

I agree that the CMake file, which is base on something that I have written more than 10 years ago, needs some modernisation.

but, just because the template in the slack build is incorrect does not mean I have to reproduce this ;-)

flags like -02 are in CMAKE_CXX_FLAGS_${BUILD_CONFIGURATION}. This is how CMake works and what CMake does by default.
so getting rid of CMAKE_CXX_FLAGS_${BUILD_CONFIGURATION} is not possible.
not using a build configuration is, but I have to think about this since this is an option I usually explicit disable, for reasons too long to explain here and now.

however, I hope, after the modernisation, no one will notice anything anymore and you will be able to use CMake in a somehow sloppy way

CMAKE_C_FLAGS is needed if internal sqlite is used because this has some options, but I should set this only if no system sqlite is used.

added this as an issue
https://bitbucket.org/a4z/sbbdep/iss...the-cmake-file

so in future I hope I will be able to deliver a build that fits for all

thank you all for the feedback, this helps me a lot to understand user needs better!

I always pass the CMAKE_C_FLAGS and CMAKE_CXX_FLAGS in every build.

The real problem in my opinion is CMAKE_C_FLAGS:STRING and CMAKE_CXX_FLAGS:STRING, they replace the compiler flags, not add to them. Would this be true of all builds or does it depend a lot on how the CMakeList.txt files are written?

These are the flags passed to cc: -O2 -fPIC -O3 -DNDEBUG (in my original build)
These are the flags passed to cc++: -O2 -fPIC -pthread -O3 -DNDEBUG

I will be replacing those with the CMAKE_C_FLAGS_RELEASE:STRING and CMAKE_CXX_FLAGS_RELEASE:STRING. The CMake Manual is a bit sparse on explaining usage of these, for example the STRING part. Leaving it out has no effect, flags are passed and added to developer flags.

These are the flags passed to cc: -Wall -Wextra -pedantic -std=c11 -pipe -O2 -fPIC
These are the flags passed to cc++: -Wall -Wextra -pedantic -std=c++14 -pipe -pthread -O2 -fPIC

One would think these would act in the same way. The only The only differences I see are the first is "Flags for all build types." The second is is for Release types. I read this a you can set different flags based on build types. Passing those flags should add to not replace. Perhaps my logic is flawed. .

Learned a lot about CMake variables today.

Originally Posted by a4z however, I hope, after the modernisation, no one will notice anything anymore and you will be able to use CMake in a somehow sloppy way CMAKE_C_FLAGS is needed if internal sqlite is used because this has some options, but I should set this only if no system sqlite is used. added this as an issue https://bitbucket.org/a4z/sbbdep/iss...the-cmake-file so in future I hope I will be able to deliver a build that fits for all thank you all for the feedback, this helps me a lot to understand user needs better!

Actually I was looking at me, using outdated CMAKE variables. I just learned about those two used in the SBo script and plan to implement them in my scripts. The program works regardless of the flags though as far as I can tell. Gonna rebuild with the correct CMake variables. Again thanks.

the old concept I use in sbbdep:
the general compiler flags should contain those flags absolute required to build, regardless of the build configuration
this is CMAKE_C(XX)_FLAGS and contains no optimisation flags or debug flags, but always warn and use pthread and whatever
optimisation flags, or no optimisation + debug, is than in the CMAKE_C(XX)_FLAGS_${BUILD_CONFIG}
with this combination you will always end up with the right flags


however, since it is impossible to change user habits, and setting this flags in this way is somehow ancient anyway and generally misunderstood
I should switch to modern cmake:
modern cmake let you set target properties, and I can and will use this instead of the concept above.
than the required flags will just be there, no matter what the user does (as long a the cmakefile is not changed by its own)

I have this on a (virtual) todo list since some time, good to have a trigger now to make it happen.

about the STRING for variables:
the STRING part of the variable is just a type hint for cmake, and totally useless since for cmake everything is a string, but for PATH or BOOL it could make more sense
usually CMake detects the types automatically, I use them more as some kind of documentation

--
for all that are interested a bit more in CMake:
if you are looking for a good CMake intro, we had last month a workshop at our C++ user group and we have it on video
https://www.youtube.com/watch?v=jt3meXdP-QI

this is a beginner tutorial, IMHO the best one available on currently, plus links to workshop examples (and solutions), and they are pretty cool

Thanks for the link to that video, I learned a few things, actually a lot.

I can think of a ton of questions right now, but for the sake of staying on topic, will pass. I will be interesting to see what changes you make make with sbbdep.