How to copy the auxiliary files


I am trying to create an PKGBUILD (installation file used from the package manager of the distribution) in Archlinux for the radiance. I have a question though regarding how the auxiliary files should be copied in the final package.

As I understand I need first to overlay the ray folder from the to over the initial extracted source code folder and then after the compilation to copy the lib folder into the /<installed_path>/lib/ray and set the RAYPATH environment parameter to this path. Is that correct?

Two questions though:

  1. Could I just copy the lib folder into the /<installed_path>/lib/ instead and not set the RAYPATH parameter? Is it the same?
  2. What is the purpose of the obj folder since from what I’ve seen it is not used/copied anywhere?

Also to mention that the pointed official stable release downloaded from here fails to compile because the resources folder is not existing inside the tar:

CMake Error at CMakeLists.txt:148 (add_subdirectory):
add_subdirectory given source "resources" which is not an existing

Thus either someone needs to go with the HEAD version instead or comment the corresponding line in the CMakelists.txt

Moreover, could someone explain a bit what it the purpose of this line in the InstallRules. I had to comment it, in order to be able to compile correctly otherwise it fails.

Welcome to the Radiance forum! I’m not familiar with Arch Linux, but since you’re using CMake, here are a few tips that are meant to apply to all operating systems. (I make no guarantees for OS’s that I haven’t worked with, but this has worked for me on Windows, Mac, and Ubuntu.)

  1. You can enable BUILD_LIBTIFF in CMake. This will automate the download of auxiliary files and place them appropriately so that you don’t need to think about it. This might take care of your add_subdirectory error as well.
  2. You must to add /<installed_path>/lib/ to the RAYPATH. Otherwise, Radiance will not find the files saved in /<installed_path>/lib/. Generally, your RAYPATH should look something like .:/<installed_path>/lib on Mac/Linux or .;C:\<installed_path>\lib on Windows.
  3. When a program is compiled, temporary object files are saved in the obj directory. This directory is not needed after compilation finishes.
  4. The line you highlighted in InstallRules is related to the resources needed to compile rvu. Make sure you have installed Qt or X11, as appropriate to your system.

Hope this helps.


Hi Nathaniel,

Thank you for the feedback. Some comments:

  1. If I activate the BUILD_LIBTIFF flag in CMake (thanks for letting me know) this will indeed download the libtiff related dependencies but not the other folders included in the radR52supp.tar.gz tarball in case you go with the HEAD version. Also in case that you have already libtiff installed in your system it seems to use these libs so activating is not that critical. Btw it does not solve the add_subdirectory for the resources folder.
  2. So setting the RAYPATH it necessary in any case, that’s fine. However, where should I copy the extra libs from the radR52supp.tar.gz lib folder. In <installed_path>/lib or in <installed_path>/lib/ray/lib
  3. the obj folder from the radR52supp.tar.gz it doesn’t seem to be used even in the compilation. In any case, it seems, as you said, that I can ignore it.
  4. Ok, so as long as Qt and X11 are installed in my system I can ignore this line and rvu will compile without issues, right?

The files in lib are not used during compilation. They are only accessed during runtime, and except for, Radiance can run without them unless they are referenced in the command line or the .rad file.

As long as your RAYPATH correctly points to the file location, it does not matter whether that path is lib or lib/ray/lib. But generally, if there is a folder where you are keeping relevant files, that folder should be included in RAYPATH.

I thought you were referring to a different obj directory. Never mind, in that case.

I’m not sure what you mean by “ignore this line.” Did rvu compile without issues? In that case, you’re fine.


There are actually a fair number of library files that get installed during compilation based on the compile-time setting of the $(LIBDIR) variable in make, or the “lib” subdirectory of ${CMAKE_BINARY_DIR} using cmake. All that is 100% necessary to run Radiance is included in the source tree.

There are some files that are needed to make scripts such as falsecolor work, like “helvet.fnt”, so do include the auxiliary files in your distro if you can. The reason they were separated out from the main source tree is because some of them take up significant space, and they don’t often change.

Regarding libtiff, you can build without it, but you won’t be able to build ra_tiff or normtiff or a few others in the src/px directory, I think.

You don’t need both Qt and X11. I would say X11 by itself is enough, as a lot of stuff won’t build without it.

The top level explains how to build binaries and copy the libraries using the “makeall” script there, which should work fine under Linux if you’ve installed the C-shell. If you prefer cmake, that build system works as well.

There are tests you can run to make sure everything installed properly and is functional in the ray/test directory. Run “make all clean” in each of the test/renders, test/util, test/gen, test/cal, and test/px subdirectories. The only one that takes some time is test/renders, so you can run “make -j 4” or whatever there.

Finally, regarding the obj folder in the auxiliary files, these are example Radiance scenes for people to get familiar with the software and use as a resource.

Thank you both @Nathaniel_Jones and @Greg_Ward for the feedback.

It seems that I have all the needed info now. I am able to build the package for my distribution without problems using CMAKE and based on the HEAD version (the official stable still complaints for the resources sub_directory, which if I disable the corresponding intro line, i.e. 148, in the CMakelists.txt works also fine).

The current CVS head is preferred over the last official release, which is quite old at this point. We plan to roll out a new one very soon!

1 Like