Unable to compile with -DARES_ENABLE_LIBRASHADER=OFF

[htv04]

Describe the bug
With the -DARES_ENABLE_LIBRASHADER=OFF compile option, intended to disable librashader support, Ares fails to build at the CMake configuration step.

Error:

CMake Error at ruby/cmake/os-linux.cmake:130 (target_link_libraries):
  Target "ruby" links to:

    librashader::librashader

  but the target was not found.  Possible reasons include:

    * There is a typo in the target name.
    * A find_package call is missing for an IMPORTED target.
    * An ALIAS target is missing.

Call Stack (most recent call first):
  ruby/CMakeLists.txt:36 (include)

To Reproduce
Add -DARES_ENABLE_LIBRASHADER=OFF to the compile options.

Expected behavior
According to this code:

ares/cmake/finders/Findlibrashader.cmake

Lines 123 to 136 in fd8bcad

	# fallback to defining a target with the header, so everything still compiles
	if(NOT TARGET librashader::librashader)
	if(librashader_INCLUDE_DIR)
	add_library(librashader INTERFACE)
	set_target_properties(librashader PROPERTIES INTERFACE_INCLUDE_DIRECTORIES "${librashader_INCLUDE_DIR}")
	add_library(librashader::librashader ALIAS librashader)
	if(ARES_ENABLE_LIBRASHADER)
	message(
	AUTHOR_WARNING
	"Tried to configure with librashader, but the library was NOT found. ${librashader_ERROR_REASON}"
	)
	endif()
	endif()
	endif()

A fallback target is supposed to be used in place of an actual librashader target. However, ruby still fails to configure at this line:

ares/ruby/cmake/os-linux.cmake

Line 135 in fd8bcad

$<$<BOOL:TRUE>:librashader::librashader>

If I understand the intended functionality of the fallback target correctly, this should not occur.

In addition, when commenting out this line, the build actually starts, but eventually fails when it cannot find the librashader headers. Perhaps this is another issue?

Additional context
I am compiling the master branch (at 639ebe6) on Linux. Here are my compile options:

-G Ninja -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DARES_BUILD_LOCAL=OFF -DARES_ENABLE_MINIMUM_CPU=OFF -DENABLE_CCACHE=OFF -DENABLE_IPO=OFF -DARES_UNITY_CORES=OFF -DARES_BUNDLE_SHADERS=OFF -DARES_SKIP_DEPS=ON -DWITH_SYSTEM_ZLIB=ON -DARES_ENABLE_LIBRASHADER=OFF -DARES_ENABLE_ALSA=ON -DARES_ENABLE_AO=OFF -DARES_ENABLE_OPENAL=OFF -DARES_ENABLE_OSS=OFF -DARES_ENABLE_PULSEAUDIO=ON -DARES_ENABLE_SDL=ON -DARES_ENABLE_UDEV=ON -DARES_ENABLE_UHID=OFF

[jcm93]

The librashader header is currently required to build ares even if ARES_ENABLE_LIBRASHADER is OFF.

We currently by default fetch the librashader header from the latest ares-deps release at configure-time to make it available.

However, you are configuring with -DARES_SKIP_DEPS=ON, so the header is not being fetched.

Currently, you will need to either:

• Not skip dependencies so the header is fetched,
• Supply a prefix containing the header yourself as part of CMAKE_PREFIX_PATH, or
• Install librashader in normal system paths so the header is located.

[htv04]

Got it, I should have figured that option would fetch the headers, too. The headers also seem to be available under thirdparty/librashader/include, is it possible to configure ares to fetch them from here instead?

[jcm93]

That is certainly technically possible, but I would not recommend relying on that indefinitely. the inclusion of the entire librashader repo under thirdparty is a function of how the legacy build system worked, and I expect all dynamic dependency code will be removed from the repo whenever the legacy build system is removed (in the relatively near future).

I am still thinking about the best way to handle the librashader header, particularly keeping in mind Linux where I am definitely aware that "download stuff as part of configuration" is not the best of patterns. If all dynamic dependency code is removed, it's possible that we would end up leaving just the header in-tree to alleviate this issue (if librashader linking is not reworked entirely by that point) given the hard dependency. I am certainly open to feedback on this; in any case it will be kept in mind going forward.

[htv04]

I would not recommend relying on that indefinitely. the inclusion of the entire librashader repo under thirdparty is a function of how the legacy build system worked

Ah, I see. The reason I ask is because I would rather avoid downloading ares-deps if possible. I'm trying to set up ares for a package manager (Portage), and the network is sandboxed during the build process, forcing me to hardcode the download URL as a source along with some ugly code to mimic the download/extract/hash process that the CMake script does.

One way to mitigate this might be if the release tags for ares-deps matched ares, as it currently uses a date. This wouldn't help for master builds, though, as there's a risk of version mismatch.

it's possible that we would end up leaving just the header in-tree to alleviate this issue

If the header is totally necessary for compilation, that might be the best way to do this. I wouldn't consider it a hack either, as it's pretty much the same as including a header-only library.

[jcm93]

You shouldn't need to do any duplication of the specific handling ares does for ares-deps. If you need the build system to find a dependency in a specific location (in this case the librashader header), all you should need to do is pass -DCMAKE_PREFIX_PATH=<path> at configure time, where path is a directory that contains the subdirectory structure include/librashader/librashader_ld.h.

(er, sorry, the above applies IF you can make the librashader header available somewhere on disk for your package to see, which may be the difficulty)

[chyyran]

Both librashader_ld.h and librashader.h are intended to be vendored and modified as appropriate for whatever needs to link to librashader dynamically.

It’s up to the application to declare the supported API version which is defined as LIBRASHADER_CURRENT_VERSION in librashader.h. If this gets pulled in via package manager instead for a more recent API than the application expects, behaviour could change in ways that don’t cause a compilation error.

For example, I had considered switching the default behaviour of the Vulkan runtime from dynamic rendering to render-pass based rendering over an API bump from 0 to 1. If LIBRASHADER_CURRENT_VERSION remains 0, then the old behaviour (dynamic-by-default) would apply, otherwise if it’s 1 then renderpass-by-default would apply.

Due to lack of users at the time I ended up switching the default behaviour to render-passes across all API versions, but that’s just one example of something that would have been allowed to change across an API bump. If I were to make such a change today, it would only take place across an API bump from 2 to 3.

[jcm93]

As of the legacy build system removal yesterday, the librashader headers (by themselves) are back in the ares source tree now. Hence, you should be able to build without librashader without requiring any external resources. Let me know if you have any further issues.