[CMake] Restore old way of importing Notcurses into a cmake project

[grendello]

Partially reverts: c5c9432
Context: #1146

The above commit implemented the much more convenient way of finding and
using a package from CMake, however it broke compatibility with the way
id had been before, which defined various Notcurses_* variables.

Revert the Notcurses component to the old way and add support for
Notcurses++ in the same fashion.

Perhaps one day we should think of implementing find_package support
by way of a module, which should make it possible to have the cake and
eat the cake. One day.

[dankamongmen]

Wait, I thought the old definitions were coming from pkg-config. If I switched over to your new CMakey solution, yeah, I have to update my references, but that's part of the cost. Or am I missing something?

I just wanted to make sure nothing broke if one was using a pure pkg-config approach, like growlight is for instance. And so far as I can tell, nothing does.

[grendello]

Wait, I thought the old definitions were coming from pkg-config. If I switched over to your new CMakey solution, yeah, I have to update my references, but that's part of the cost. Or am I missing something?

They come from the *Config.cmake files we generate, pkg_config isn't apparently involved. Incidentally, I think the files we generate are actually broken, here's what I get:

####### Expanded from @PACKAGE_INIT@ by configure_package_config_file() #######
####### Any changes to this file will be overwritten by the next CMake run ####
####### The input file was NotcursesConfig.cmake.in                            ########

get_filename_component(PACKAGE_PREFIX_DIR "${CMAKE_CURRENT_LIST_DIR}/../../../" ABSOLUTE)

macro(set_and_check _var _file)
  set(${_var} "${_file}")
  if(NOT EXISTS "${_file}")
    message(FATAL_ERROR "File or directory ${_file} referenced by variable ${_var} does not exist !")
  endif()
endmacro()

macro(check_required_components _NAME)
  foreach(comp ${${_NAME}_FIND_COMPONENTS})
    if(NOT ${_NAME}_${comp}_FOUND)
      if(${_NAME}_FIND_REQUIRED_${comp})
        set(${_NAME}_FOUND FALSE)
      endif()
    endif()
  endforeach()
endmacro()

####################################################################################
set(Notcurses_DIR "")

# Compute paths
get_filename_component(Notcurses_CMAKE_DIR "${CMAKE_CURRENT_LIST_FILE}" PATH)
set(Notcurses_INCLUDE_DIRS "")
set(Notcurses_LIBRARY_DIRS "")

set(Notcurses_LIBRARIES -lnotcurses)

Note the *_DIRS variables are empty.

I just wanted to make sure nothing broke if one was using a pure pkg-config approach, like growlight is for instance. And so far as I can tell, nothing does.

Pure pkg-config would look like:

pkg_check_modules(NOTCURSES REQUIRED notcurses>=2.0.8)

find_package might fall back to pkg-config if it doesn't find any *Config.cmake etc files for a package - but in our case it does find them, so I doubt it goes any farther than that.

[dankamongmen]

[deletia]

avast! sacre bleu!

[dankamongmen]

https://www.youtube.com/watch?v=jAotm74ek4c @grendello

[dankamongmen]

/""\

[grendello]

I wonder how come it works for you in glowlight - on my system, with those files in place, Notcurses does get detected but the build fails because lib path is empty, so is include path.

[dankamongmen]

probably because i've got the debian libnotcurses-dev package installed, so it's in standard locations

[grendello]

That might be it, I don't have it installed (on purpose). So maybe we can switch to the namespace::component system after all without breaking backward compatibility?