3.0.0 release can't be (easily) compiled from source

[ernstki]

The errors below apply to macOS 10.14 (Mojave) using MacPorts and Debian 10.2 (Buster).

Attempting to build master from a Git clone, I quickly came upon #5, so I downloaded and unpacked the 3.0.0 release tarball instead.

Attempting to build in the usual way with CMake, I received the error message:

CMake Error at CMakeLists.txt:105 (find_package):
  By not providing "FindRinutils.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "Rinutils",
  but CMake did not find one.

  Could not find a package configuration file provided by "Rinutils" with any
  of the following names:

    RinutilsConfig.cmake
    rinutils-config.cmake

  Add the installation prefix of "Rinutils" to CMAKE_PREFIX_PATH or set
  "Rinutils_DIR" to a directory containing one of the above files.  If
  "Rinutils" provides a separate development package or SDK, be sure it has
  been installed

I then git cloned Rinutils into the fortune-mod directory and attempted to build it in the usual CMake way, but got this error:

CMake Warning at cmake/shlomif_common_bootstrap.cmake:7 (MESSAGE):
  Could not find Shlomif_Common.cmake - you can find it here:
  https://github.com/shlomif/shlomif-cmake-modules ; trying to download it
  for you.
Call Stack (most recent call first):
  CMakeLists.txt:4 (INCLUDE)


CMake Error at CMakeLists.txt:5 (SHLOMIF_COMMON_SETUP):
  Unknown CMake command "SHLOMIF_COMMON_SETUP".

Having seen #5 from the fortune-mod repo, I had some idea how to proceed here, so I downloaded the rinutils 0.4.1 release tarball, unpacked it, and attempted to build that in the usual CMake way. However, then I ran into this:

-- Checking for module 'cmocka'
--   No package 'cmocka' found
CMake Error at /usr/local/cmake/3.8.1/share/cmake-3.8/Modules/FindPkgConfig.cmake:416 (message):
  A required package was not found
Call Stack (most recent call first):
  /usr/local/cmake/3.8.1/share/cmake-3.8/Modules/FindPkgConfig.cmake:589 (_pkg_check_modules_internal)
  CMakeLists.txt:150 (pkg_check_modules)

At this point, I'm sorry to say, I gave up. Neither Rinutils nor fortune-mod mentioned the cmocka dependency, and I was able to get the old tarball from '97 working with only the basic kit and minor changes to the Makefile.

I realize that last part is more or less a rinutils problem, and probably should be tracked in rinutils' issue tracker simple matter of apt install libmocka-dev or port install cmocka and then try again. But with all due respect, wouldn't it be prudent to try to incorporate whatever bits and bobs you need from the Rinutils repo into the fortune-mod one (maybe as a submodule), so that it can build in the expected way with git clone …; mkdir build; cd build; cmake ..?

[shlomif]

Hi! I have made the rinutils test suite turned off by default in release 0.6.0 (see https://github.com/shlomif/rinutils/releases/tag/0.6.0 ) which avoids requiring cmocka. I should note that you can refer to the .travis.yml ( https://github.com/shlomif/fortune-mod/blob/master/.travis.yml ) for definitive specification of requirements (documentation can lie - running code less so: https://blog.codinghorror.com/learn-to-read-the-source-luke/ ). Anyway, I'd like to embed rinutils into a submodule similar to what I did in fc-solve so thanks for your suggestion. Stay tuned.

[shlomif]

@ernstki : hi! Please try again with the just published 3.2.0 version: https://github.com/shlomif/fortune-mod/releases/tag/fortune-mod-3.2.0 . Thanks!

I also noticed that fc-solve checked out rinutils v0.2.0 by default which is rather old so I'm working on an update. Thanks again.

[ernstki]

Hi, @shlomif. Thanks for having a look at this. It's on my "list" to have another go with the new release, but you know how those things go. Fortunately the new notifications system in GitHub won't let me forget!

Wow, it looks intimidating. And I thought some of my FOSS projects had too many prereqs! Of course, some users will still complain even if there is a moderate number of deps, which are even explicitly specified in the CI configuration.

Characterizing this as a "complaint" is isn't unfair; after all some amount of drive-by kvetching in a public issue tracker is to be expected, I think? ;) I also think your point about GNU Parallel's test suite being "indimidating" is a fair criticism.

At the time, I was focused on documenting the error messages rather than summing up the philosophical argument at the core of this issue. Maybe the philosophical argument would've been more to the point. However, given some time to reflect, it's this:

The project should build from a release tarball or git clone using the process stated in the README (or in this case, INSTALL) file. Hopefully that's an uncontroversial statement. It seems just a tiny bit more work is needed to either update the documentation or simplify the process of getting those dependencies in place.

I understand what Atwood is getting at, in the context of a fast-moving API in a project that's in heavy development. But in this context, and with all due respect to you and Atwood, I'm not sure it's right to expect anyone to look inside a (hidden) CI configuration file to figure out how to satisfy essential build dependencies.

Cheers,
Kevin

[shlomif]

Hi @ernstki !

Hi, @shlomif. Thanks for having a look at this. It's on my "list" to have another go with the new release, but you know how those things go. Fortunately the new notifications system in GitHub won't let me forget!

OK, thanks!

Wow, it looks intimidating. And I thought some of my FOSS projects had too many prereqs! Of course, some users will still complain even if there is a moderate number of deps, which are even explicitly specified in the CI configuration.

Characterizing this as a "complaint" is isn't unfair; after all some amount of drive-by kvetching in a public issue tracker is to be expected, I think? ;) I also think your point about GNU Parallel's test suite being "indimidating" is a fair criticism.

I see.

At the time, I was focused on documenting the error messages rather than summing up the philosophical argument at the core of this issue. Maybe the philosophical argument would've been more to the point. However, given some time to reflect, it's this:

The project should build from a release tarball or git clone using the process stated in the README (or in this case, INSTALL) file. Hopefully that's an uncontroversial statement. It seems just a tiny bit more work is needed to either update the documentation or simplify the process of getting those dependencies in place.

OK. I intend to fix such issues as they are reported in order to prevent future support requests:

https://www.shlomifish.org/humour/fortunes/show.cgi?id=joel-remarkable-customer-service-3

I understand what Atwood is getting at, in the context of a fast-moving API in a project that's in heavy development. But in this context, and with all due respect to you and Atwood, I'm not sure it's right to expect anyone to look inside a (hidden) CI configuration file to figure out how to satisfy essential build dependencies.

I think Atwood's point was that the documentation tends to become unsynchronised with the actuak behaviour of the code because it isn't tested or run and cannot be easily tested. This applies to all software projects and from my experience even inline comments can become out of date.

I am going to update the INSTALL file but note that while the .travis.yml starts with a dot (to avoid clutter in "ls"'s output), it is right there in the repo and follows a common filename convention. See https://github.com/shlomif/fortune-mod (there is a travis-ci badge there too).

Cheers,
Kevin

[shlomif]

Regarding Characterizing this as a "complaint" is isn't unfair; assuming you meant it is unfair, then the way I see it (and I may miss some nuances of English due to being a non-native speaker) then in a way many bug reports / issue reports / "defect" reports are complaints because they follow the general pattern of "I tried doing X; instead of doing the expected Y action your software app did Z. I was disappointed by that.". Furthermore, I try (at least in ideology) to encourage complaints and other criticisms because that way I avoid the path of least resistance of not improving.

Do you agree?

[ernstki]

A more straightforward way of writing that would have been: "it is fair to characterize this issue as a 'complaint', however having a public issue tracker for an open-source project is essentially opening the door to (sometimes unhelpful) complaints from random strangers, so let's make the best of the situation." Delivered with a knowing wink and a nudge.

It's the word "complain" from your comment to the Parallel mailing list that I fixated on. "Complain" has this connotation of just spewing negativity for negativity's sake; the complainer not having anything invested in coming up with a solution. And it was obviously weighing on your mind enough for you to have mentioned it in another forum. I do not want to heap any negativity on any of the open source maintainers of the world. You do enough thankless work as it is.

So, I think we are in perfect agreement here. I do want this to be a productive discussion, and I do want to help make the project better for the next user in the same situation.

It's going to take me a while to parse all the links in that blog post, but so far there are lots of good insights there. I know I wish my coworkers and collaborators would be more forthright with constructive criticism, without worrying about hurt feelings.

[shlomif]

On Thu, 08 Oct 2020 14:49:09 -0700 Kevin Ernst ***@***.***> wrote: A more straightforward way of writing that would be: "it **is** fair to characterize this issue as a 'complaint', however having a public issue tracker for an open-source project is essentially opening the door to (sometimes unhelpful) complaints from random strangers, so let's make the best of the situation." Delivered with a knowing wink and a nudge. I think we are in perfect agreement here. I do want this to be a productive discussion, and I do want to help make the project better for the next user in the same situation. It's going to take me a while to parse al the links in that blog post, but so far there are lots of good insights there. I know *I* wish my coworkers and collaborators would be more forthright with constructive criticism, without worrying about hurt feelings.

Thanks for the reply and clarification, Kevin! I guess we agree. Re accepting criticism I am also reminded of this post by Ben Collins-Sussman about programmer insecurity: http://blog.red-bean.com/sussman/?p=96 .

…

-- Shlomi Fish I can imagine the headline: “Sarah Michelle Gellar, who played Buffy the vampire slayer, murdered in cold blood by child daughter.” — https://www.shlomifish.org/humour/Summerschool-at-the-NSA/ Please reply to list if it's a mailing list post - https://shlom.in/reply .

[johny-mnemonic]

I just tried to compile the new suggested version (3.2.0), but I am having the same issues.
First I got this error from cmake:

CMake Error at CMakeLists.txt:105 (find_package):
  By not providing "FindRinutils.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "Rinutils",
  but CMake did not find one.

  Could not find a package configuration file provided by "Rinutils" with any
  of the following names:

    RinutilsConfig.cmake
    rinutils-config.cmake

  Add the installation prefix of "Rinutils" to CMAKE_PREFIX_PATH or set
  "Rinutils_DIR" to a directory containing one of the above files.  If
  "Rinutils" provides a separate development package or SDK, be sure it has
  been installed.

So I went to rinutils dir and built it with cmake.
Then I tried to provide path to rinutils to fortune-mod cmake and ended like this:

/root/fortune-mod-3.2.0/build] cmake .. -DCMAKE_PREFIX_PATH=/root/fortune-mod-3.2.0/rinutils
CMake Error at rinutils/build/RinutilsConfig.cmake:13 (message):
  File or directory /root/include referenced by variable RINUTILS_INCLUDE_DIR
  does not exist !
Call Stack (most recent call first):
  rinutils/build/RinutilsConfig.cmake:29 (set_and_check)
  CMakeLists.txt:115 (find_package)

Any clue how to build this?

[shlomif]

Hi @johny-mnemonic !

I just tried to compile the new suggested version (3.2.0), but I am having the same issues.
First I got this error from cmake:

CMake Error at CMakeLists.txt:105 (find_package):
  By not providing "FindRinutils.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "Rinutils",
  but CMake did not find one.

  Could not find a package configuration file provided by "Rinutils" with any
  of the following names:

    RinutilsConfig.cmake
    rinutils-config.cmake

  Add the installation prefix of "Rinutils" to CMAKE_PREFIX_PATH or set
  "Rinutils_DIR" to a directory containing one of the above files.  If
  "Rinutils" provides a separate development package or SDK, be sure it has
  been installed.

As a copy of rinutils is bundled with the 3.2.0 tar.xz (see https://github.com/shlomif/fortune-mod/releases/tag/fortune-mod-3.2.0 ) then you should have got a warning instead of an error. Here is my output here (linux x86-64):

+-zsh:27> cmake ../fortune-mod-3.2.0
-- The C compiler identification is GNU 10.2.0
-- The CXX compiler identification is GNU 10.2.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /home/shlomif/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /home/shlomif/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found Perl: /usr/bin/perl (found version "5.32.0")
-- Found PkgConfig: /usr/bin/pkg-config (found version "1.7.3")
-- Performing Test FLAG_EXISTS_1
-- Performing Test FLAG_EXISTS_1 - Success
-- Performing Test FLAG_EXISTS_2
-- Performing Test FLAG_EXISTS_2 - Success
CMake Warning at CMakeLists.txt:115 (find_package):
  By not providing "FindRinutils.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "Rinutils",
  but CMake did not find one.

  Could not find a package configuration file provided by "Rinutils" with any
  of the following names:

    RinutilsConfig.cmake
    rinutils-config.cmake

  Add the installation prefix of "Rinutils" to CMAKE_PREFIX_PATH or set
  "Rinutils_DIR" to a directory containing one of the above files.  If
  "Rinutils" provides a separate development package or SDK, be sure it has
  been installed.


-- Looking for 3 include files stdbool.h, ..., recode.h
-- Looking for 3 include files stdbool.h, ..., recode.h - found
-- Looking for regex.h
-- Looking for regex.h - found
-- Configuring done
-- Generating done
-- Build files have been written to: /home/shlomif/b

Can you share more info about your OS? See: https://github.com/shlomif/writing-the-perfect-question

So I went to rinutils dir and built it with cmake.
Then I tried to provide path to rinutils to fortune-mod cmake and ended like this:

/root/fortune-mod-3.2.0/build] cmake .. -DCMAKE_PREFIX_PATH=/root/fortune-mod-3.2.0/rinutils
CMake Error at rinutils/build/RinutilsConfig.cmake:13 (message):

You should try to avoid compiling as root (only run make install/etc. as root if necessary). I think it isn't the culprit here, though.

[johny-mnemonic]

Oh, OK.
So it seems like the main issue was I tried to fix that warning you mention :-D
When I tried to clean everything and run cmake again it did the same thing as yours. Only Warning for Rinutils, not Error.

BTW: I am on the CentOS 8 where the fortune-mod package is missing in epel...

Thanks for help!

[shlomif]

Oh, OK.
So it seems like the main issue was I tried to fix that warning you mention :-D
When I tried to clean everything and run cmake again it did the same thing as yours. Only Warning for Rinutils, not Error.

BTW: I am on the CentOS 8 where the fortune-mod package is missing in epel...

Thanks for help!

You're welcome. Thanks for the update. There may be a way to make the cmake warning less noisy and not as scary. I'd like to try to investigate it (see: https://www.joelonsoftware.com/2007/02/19/seven-steps-to-remarkable-customer-service/ ).

[bartclone]

On MacOS . Did a git clone, brew install cmake.

But nice to mention this Issue in the error..

Could not find rinutils anywhere - it should have been bundled in the
  releases' source tarball.

 Also see: https://github.com/shlomif/fortune-mod/issues/44

Question: what the heck are rinutils? And where to find these?

However, I really agree with @ernstki and @johny-mnemonic This is 'just' a C-program? (Or is it a reference how a fortune should work?).
Please, KISS: make|cmake should just work.

Tried the tarball too: dependency hell 3.2?

CMake Warning at CMakeLists.txt:115 (find_package):
  By not providing "FindRinutils.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "Rinutils",
  but CMake did not find one.

  Could not find a package configuration file provided by "Rinutils" with any
  of the following names:

    RinutilsConfig.cmake
    rinutils-config.cmake

  Add the installation prefix of "Rinutils" to CMAKE_PREFIX_PATH or set
  "Rinutils_DIR" to a directory containing one of the above files.  If
  "Rinutils" provides a separate development package or SDK, be sure it has
  been installed.


CMake Error at CMakeLists.txt:141 (MESSAGE):
  Cannot find recode.h anywhere - please install lib recode

-- Configuring incomplete, errors occurred!
See also "/Users/bart/Testing/fortune-mod-3.2.0/CMakeFiles/CMakeOutput.log".
See also "/Users/bart/Testing/fortune-mod-3.2.0/CMakeFiles/CMakeError.log".

[shlomif]

Hi @BartKoppers !

On MacOS . Did a git clone, brew install cmake.

But nice to mention this Issue in the error..

Could not find rinutils anywhere - it should have been bundled in the
  releases' source tarball.

 Also see: https://github.com/shlomif/fortune-mod/issues/44

Question: what the heck are rinutils? And where to find these?

The cmake on the git master HEAD now calls "git submodule" which should hopefully streamline the build procedure: be1e8e9 . I'll also clarify the message so one will know rinutils an be found at https://github.com/shlomif/rinutils .

However, I really agree with @ernstki and @johny-mnemonic This is 'just' a C-program? (Or is it a reference how a fortune should work?).
Please, KISS: make|cmake should just work.

The problem is that https://en.wikipedia.org/wiki/Don%27t_repeat_yourself is often at odds with KISS.

Tried the tarball too: dependency hell 3.2?

CMake Warning at CMakeLists.txt:115 (find_package):
  By not providing "FindRinutils.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "Rinutils",
  but CMake did not find one.

  Could not find a package configuration file provided by "Rinutils" with any
  of the following names:

    RinutilsConfig.cmake
    rinutils-config.cmake

  Add the installation prefix of "Rinutils" to CMAKE_PREFIX_PATH or set
  "Rinutils_DIR" to a directory containing one of the above files.  If
  "Rinutils" provides a separate development package or SDK, be sure it has
  been installed.


CMake Error at CMakeLists.txt:141 (MESSAGE):
  Cannot find recode.h anywhere - please install lib recode

librecode is at https://github.com/rrthomas/recode . It will be prohibitive to bundle it, but I suppose I can make its use optional and/or clarify the error message.

-- Configuring incomplete, errors occurred!
See also "/Users/bart/Testing/fortune-mod-3.2.0/CMakeFiles/CMakeOutput.log".
See also "/Users/bart/Testing/fortune-mod-3.2.0/CMakeFiles/CMakeError.log".

Thanks!

[johny-mnemonic]

@shlomif You are doing terrific job here! Thanks
That Joels article on customer support is awesome and I felt humiliated when I found out it is from 2007 and I didn't discover it before. This should be in top five links of every beginner dev, together with how to write git commits!

Would you please share what would one miss when fortune-mod is compiled without recode library?
Should we expect issues with non-unicode fortune sources or sources in 'weird' char sets?

[shlomif]

Hi @johny-mnemonic !

@shlomif You are doing terrific job here! Thanks
That Joels article on customer support is awesome and I felt humiliated when I found out it is from 2007 and I didn't discover it before. This should be in top five links of every beginner dev, together with how to write git commits!

Would you please share what would one miss when fortune-mod is compiled without recode library?
Should we expect issues with non-unicode fortune sources or sources in 'weird' char sets?

From what I can tell from reading the source, what recode allows fortune-mod to do is to translate the fortune cookies from UTF-8 (which is the encoding in which they are stored) to the user's locale's native encoding (which may be different). If librecode is not used, they are emitted as is, which should be in UTF-8. I expect most end users to use a UTF-8 locale now, but practice is different from theory. 😉

Re Joel on Software, I have a collection of some of my favourite quotes of his with links to the original posts. The XML sources are converted to either XHTML or a fortune-compatible format.

[shlomif]

Update: Some other issues with building fortune-mod should have been resolved in the just published 3.4.0 release (which also has some new quotes). I'd appreciate if you can try building it.

[bartclone]

I'm sorry, but I'm starting to wonder what you'd like us to test (and how)?

Update: Some other issues with building fortune-mod should have been resolved in the just published 3.4.0 release (which also has some new quotes). I'd appreciate if you can try building it.

Did a fresh git clone on the untarred release .xz

mkdir build; cd build
bart at MacBook-Pro-BK in build
$ cmake ..
CMake Warning at CMakeLists.txt:153 (MESSAGE):
Cannot find recode.h anywhere - for an improved user experience please
install the recode library: https://github.com/rrthomas/recode
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/bart/Testing/fortune-mod-3.4.0

Well, oke. Recode is missing.
I could not find instructions in your repo how to integrate this recode-project somehow.

So, I looked at and cloned https://github.com/rrthomas/recode.
But AFAIK there are no Build instructions in the recode repo.
It states an INSTALL but it's not there. The README is a mess.

And now?

TBH, I am starting to get a bit annoyed here.
That's ofcourse not your intention and/or problem, as maybe I am just not familiar enough with the complexity this fortune project introduces.
Still, a pity.

[shlomif]

@BartKoppers : you likely do not need recode, and you should install it from the source tarball if you still want it. Anyway, I rephrased the warning in 74dd15f . TBH, I am a little annoyed as well, but I guess this is "shrinkwrap" software for you.

[johny-mnemonic]

@BartKoppers I don't think it is fair blaming @shlomif for recode library not having clear install instructions visible in github mate.
Been there finding installation instructions as well and found, that the INSTALL file is only in the tarball, but not in the repository...not sure why.
Go complain to recode author for that though.

[bartclone]

@shlomif Haha - shrinkwrap , really funny!
Don't know how you want us to see where this project's world is? 
As I read, Joel's options are: shrinkwrap, internal, embedded, games or throwaway.....)

Thanks for all your time and efforts here. It compiles now, so a happy 'shrinkwrap user' here.
Still some issues, but won't be bothering you with them before I dive in them myself first. If my programming skills just weren't that rusty :).

PS: @johny-mnemonic don't be silly - I never blamed anyone for the recode project, let alone @shlomif
PS: I blame myself for not easily finding my way in all these repo's and the instructions that I cannot find.

[shlomif]

@BartKoppers : Joel notes that shrinkwrap can be "shareware or open source or GNU or whatever" which (I believe) is the case for fortune-mod. The decision to use recode was present in the pre-cmake f-mod 1.99.1 , and while I originally planned to find an alternative, it was adopted by rrthomas. Using it is now a build time option. I'm looking forward for your contributions, but I have enough FOSS/free-culture work to meanwhile do.

[shlomif]

Hi everyone! Is everyone happy now with the build process user-experience of the latest release source tarballs and the one from the git clone? May I close this ticket? Happy thanksgiving/black friday/etc. in case that's your thing.

[shlomif]

Closing for now to avoid clutter. I can reopen it if necessary.

[ernstki]

The notification from GitHub about this has been sitting in my inbox (a.k.a., my to-do list) for some weeks now as a reminder, I just haven't had a chance to try to build it again in our environment. I think we're probably good though, and thanks for your efforts, @shlomif!