Implement a resource system.
Currently, icons, fonts, etc are converted to C structures at compile
time and are hardcoded to the binary. This presents several problems:
* Cross-compilation is complicated. Right now, it is necessary
to be able to run executables for the target platform; this
happens to work with wine-binfmt installed, but is rather ugly.
* Icons can only have one resolution. On OS X, modern software is
expected to take advantage of high-DPI ("Retina") screens and
use so-called @2x assets when ran in high-DPI mode.
* Localization is complicated. Win32 and OS X provide built-in
support for loading the resource appropriate for the user's
locale.
* Embedding strings can only be done as raw strings, using C++'s
R"(...)" literals. This precludes embedding sizable strings,
e.g. JavaScript libraries as used in Three.js export, and makes
git history less useful. Not embedding the libraries means we
have to rely on external CDNs, which requires an Internet
connection and adds a glaring point of failure.
* Linux distribution guidelines are violated. All architecture-
independent data, especially large data such as fonts, is
expected to be in /usr/share, not in the binary.
* Customization is impossible without recompilation. Minor
modifications like adding a few missing vector font characters
or adjusting localization require a complete development
environment, which is unreasonable to expect from users of
a mechanical CAD.
As such, this commit adds a resource system that bundles (and
sometimes builds) resources with the executable. Where they go is
platform-dependent:
* on Win32: into resources of the executable, which allows us to
keep distributing one file;
* on OS X: into the app bundle;
* on other *nix: into /usr/share/solvespace/ or ../res/ (relative
to the executable path), the latter allowing us to run freshly
built executables without installation.
It also subsides the platform-specific resources that are in src/.
The resource system is not yet used for anything; this will be added
in later commits.
2016-04-21 15:54:18 +00:00
|
|
|
# First, set up registration functions for the kinds of resources we handle.
|
|
|
|
set(resource_root ${CMAKE_CURRENT_SOURCE_DIR}/)
|
|
|
|
set(resource_list)
|
|
|
|
if(WIN32)
|
2016-06-02 02:18:29 +00:00
|
|
|
configure_file(${CMAKE_CURRENT_SOURCE_DIR}/win32/versioninfo.rc.in
|
|
|
|
${CMAKE_CURRENT_BINARY_DIR}/win32/versioninfo.rc)
|
|
|
|
|
Implement a resource system.
Currently, icons, fonts, etc are converted to C structures at compile
time and are hardcoded to the binary. This presents several problems:
* Cross-compilation is complicated. Right now, it is necessary
to be able to run executables for the target platform; this
happens to work with wine-binfmt installed, but is rather ugly.
* Icons can only have one resolution. On OS X, modern software is
expected to take advantage of high-DPI ("Retina") screens and
use so-called @2x assets when ran in high-DPI mode.
* Localization is complicated. Win32 and OS X provide built-in
support for loading the resource appropriate for the user's
locale.
* Embedding strings can only be done as raw strings, using C++'s
R"(...)" literals. This precludes embedding sizable strings,
e.g. JavaScript libraries as used in Three.js export, and makes
git history less useful. Not embedding the libraries means we
have to rely on external CDNs, which requires an Internet
connection and adds a glaring point of failure.
* Linux distribution guidelines are violated. All architecture-
independent data, especially large data such as fonts, is
expected to be in /usr/share, not in the binary.
* Customization is impossible without recompilation. Minor
modifications like adding a few missing vector font characters
or adjusting localization require a complete development
environment, which is unreasonable to expect from users of
a mechanical CAD.
As such, this commit adds a resource system that bundles (and
sometimes builds) resources with the executable. Where they go is
platform-dependent:
* on Win32: into resources of the executable, which allows us to
keep distributing one file;
* on OS X: into the app bundle;
* on other *nix: into /usr/share/solvespace/ or ../res/ (relative
to the executable path), the latter allowing us to run freshly
built executables without installation.
It also subsides the platform-specific resources that are in src/.
The resource system is not yet used for anything; this will be added
in later commits.
2016-04-21 15:54:18 +00:00
|
|
|
set(rc_file ${CMAKE_CURRENT_BINARY_DIR}/resources.rc)
|
2016-12-04 20:16:05 +00:00
|
|
|
file(WRITE ${rc_file} "// Autogenerated; do not edit\n")
|
|
|
|
file(APPEND ${rc_file} "#include <windows.h>\n")
|
|
|
|
file(APPEND ${rc_file} "#include \"${CMAKE_CURRENT_BINARY_DIR}/win32/versioninfo.rc\"\n")
|
Implement a resource system.
Currently, icons, fonts, etc are converted to C structures at compile
time and are hardcoded to the binary. This presents several problems:
* Cross-compilation is complicated. Right now, it is necessary
to be able to run executables for the target platform; this
happens to work with wine-binfmt installed, but is rather ugly.
* Icons can only have one resolution. On OS X, modern software is
expected to take advantage of high-DPI ("Retina") screens and
use so-called @2x assets when ran in high-DPI mode.
* Localization is complicated. Win32 and OS X provide built-in
support for loading the resource appropriate for the user's
locale.
* Embedding strings can only be done as raw strings, using C++'s
R"(...)" literals. This precludes embedding sizable strings,
e.g. JavaScript libraries as used in Three.js export, and makes
git history less useful. Not embedding the libraries means we
have to rely on external CDNs, which requires an Internet
connection and adds a glaring point of failure.
* Linux distribution guidelines are violated. All architecture-
independent data, especially large data such as fonts, is
expected to be in /usr/share, not in the binary.
* Customization is impossible without recompilation. Minor
modifications like adding a few missing vector font characters
or adjusting localization require a complete development
environment, which is unreasonable to expect from users of
a mechanical CAD.
As such, this commit adds a resource system that bundles (and
sometimes builds) resources with the executable. Where they go is
platform-dependent:
* on Win32: into resources of the executable, which allows us to
keep distributing one file;
* on OS X: into the app bundle;
* on other *nix: into /usr/share/solvespace/ or ../res/ (relative
to the executable path), the latter allowing us to run freshly
built executables without installation.
It also subsides the platform-specific resources that are in src/.
The resource system is not yet used for anything; this will be added
in later commits.
2016-04-21 15:54:18 +00:00
|
|
|
|
|
|
|
function(add_resource name)
|
|
|
|
set(source ${CMAKE_CURRENT_SOURCE_DIR}/${name})
|
|
|
|
|
2016-05-18 11:22:07 +00:00
|
|
|
if(${ARGC} GREATER 1)
|
|
|
|
set(id ${ARGV1})
|
|
|
|
else()
|
Implement a resource system.
Currently, icons, fonts, etc are converted to C structures at compile
time and are hardcoded to the binary. This presents several problems:
* Cross-compilation is complicated. Right now, it is necessary
to be able to run executables for the target platform; this
happens to work with wine-binfmt installed, but is rather ugly.
* Icons can only have one resolution. On OS X, modern software is
expected to take advantage of high-DPI ("Retina") screens and
use so-called @2x assets when ran in high-DPI mode.
* Localization is complicated. Win32 and OS X provide built-in
support for loading the resource appropriate for the user's
locale.
* Embedding strings can only be done as raw strings, using C++'s
R"(...)" literals. This precludes embedding sizable strings,
e.g. JavaScript libraries as used in Three.js export, and makes
git history less useful. Not embedding the libraries means we
have to rely on external CDNs, which requires an Internet
connection and adds a glaring point of failure.
* Linux distribution guidelines are violated. All architecture-
independent data, especially large data such as fonts, is
expected to be in /usr/share, not in the binary.
* Customization is impossible without recompilation. Minor
modifications like adding a few missing vector font characters
or adjusting localization require a complete development
environment, which is unreasonable to expect from users of
a mechanical CAD.
As such, this commit adds a resource system that bundles (and
sometimes builds) resources with the executable. Where they go is
platform-dependent:
* on Win32: into resources of the executable, which allows us to
keep distributing one file;
* on OS X: into the app bundle;
* on other *nix: into /usr/share/solvespace/ or ../res/ (relative
to the executable path), the latter allowing us to run freshly
built executables without installation.
It also subsides the platform-specific resources that are in src/.
The resource system is not yet used for anything; this will be added
in later commits.
2016-04-21 15:54:18 +00:00
|
|
|
string(REPLACE ${resource_root} "" id ${source})
|
|
|
|
endif()
|
2016-05-18 11:22:07 +00:00
|
|
|
if(${ARGC} GREATER 2)
|
|
|
|
set(type ${ARGV2})
|
|
|
|
else()
|
Implement a resource system.
Currently, icons, fonts, etc are converted to C structures at compile
time and are hardcoded to the binary. This presents several problems:
* Cross-compilation is complicated. Right now, it is necessary
to be able to run executables for the target platform; this
happens to work with wine-binfmt installed, but is rather ugly.
* Icons can only have one resolution. On OS X, modern software is
expected to take advantage of high-DPI ("Retina") screens and
use so-called @2x assets when ran in high-DPI mode.
* Localization is complicated. Win32 and OS X provide built-in
support for loading the resource appropriate for the user's
locale.
* Embedding strings can only be done as raw strings, using C++'s
R"(...)" literals. This precludes embedding sizable strings,
e.g. JavaScript libraries as used in Three.js export, and makes
git history less useful. Not embedding the libraries means we
have to rely on external CDNs, which requires an Internet
connection and adds a glaring point of failure.
* Linux distribution guidelines are violated. All architecture-
independent data, especially large data such as fonts, is
expected to be in /usr/share, not in the binary.
* Customization is impossible without recompilation. Minor
modifications like adding a few missing vector font characters
or adjusting localization require a complete development
environment, which is unreasonable to expect from users of
a mechanical CAD.
As such, this commit adds a resource system that bundles (and
sometimes builds) resources with the executable. Where they go is
platform-dependent:
* on Win32: into resources of the executable, which allows us to
keep distributing one file;
* on OS X: into the app bundle;
* on other *nix: into /usr/share/solvespace/ or ../res/ (relative
to the executable path), the latter allowing us to run freshly
built executables without installation.
It also subsides the platform-specific resources that are in src/.
The resource system is not yet used for anything; this will be added
in later commits.
2016-04-21 15:54:18 +00:00
|
|
|
set(type RCDATA)
|
|
|
|
endif()
|
|
|
|
file(SHA512 "${source}" hash)
|
|
|
|
file(APPEND ${rc_file} "${id} ${type} \"${source}\" // ${hash}\n")
|
|
|
|
# CMake doesn't track file dependencies across directories, so we force
|
|
|
|
# a reconfigure (which changes the RC file because of the hash above)
|
|
|
|
# every time a resource is changed.
|
|
|
|
set_property(DIRECTORY APPEND PROPERTY CMAKE_CONFIGURE_DEPENDS "${source}")
|
|
|
|
endfunction()
|
|
|
|
elseif(APPLE)
|
2018-07-17 12:45:38 +00:00
|
|
|
set(app_resource_dir ${CMAKE_BINARY_DIR}/bin/SolveSpace.app/Contents/Resources)
|
Use the same code for loading resources in all executables.
All of our executables need resources; e.g. the vector font is
a resource and it is necessary for generation. Before this commit,
the GUI executable loaded the resources in a nice way, and everything
else did it in a very ad-hoc, fragile way.
After this commit, all executables are placed in <build>/bin and
follow the same algorithm:
* On Windows, resources are compiled and linked into every
executable.
* On Linux, resources are copied into <build>/res (which is
tried first) and <prefix>/share/solvespace (which is tried
second).
* On macOS, resources are copied into <build>/res (which is
tried first) and <build>/bin/solvespace.app/Contents/Resources
(which is tried second).
In practice this means that we can add as many executables as we want
without duplicating lots of code. In addition, on macOS, we can
place supplementary executables into the bundle, and they can use
resources from the bundle transparently.
2016-11-28 04:16:18 +00:00
|
|
|
set(cli_resource_dir ${CMAKE_BINARY_DIR}/res)
|
Implement a resource system.
Currently, icons, fonts, etc are converted to C structures at compile
time and are hardcoded to the binary. This presents several problems:
* Cross-compilation is complicated. Right now, it is necessary
to be able to run executables for the target platform; this
happens to work with wine-binfmt installed, but is rather ugly.
* Icons can only have one resolution. On OS X, modern software is
expected to take advantage of high-DPI ("Retina") screens and
use so-called @2x assets when ran in high-DPI mode.
* Localization is complicated. Win32 and OS X provide built-in
support for loading the resource appropriate for the user's
locale.
* Embedding strings can only be done as raw strings, using C++'s
R"(...)" literals. This precludes embedding sizable strings,
e.g. JavaScript libraries as used in Three.js export, and makes
git history less useful. Not embedding the libraries means we
have to rely on external CDNs, which requires an Internet
connection and adds a glaring point of failure.
* Linux distribution guidelines are violated. All architecture-
independent data, especially large data such as fonts, is
expected to be in /usr/share, not in the binary.
* Customization is impossible without recompilation. Minor
modifications like adding a few missing vector font characters
or adjusting localization require a complete development
environment, which is unreasonable to expect from users of
a mechanical CAD.
As such, this commit adds a resource system that bundles (and
sometimes builds) resources with the executable. Where they go is
platform-dependent:
* on Win32: into resources of the executable, which allows us to
keep distributing one file;
* on OS X: into the app bundle;
* on other *nix: into /usr/share/solvespace/ or ../res/ (relative
to the executable path), the latter allowing us to run freshly
built executables without installation.
It also subsides the platform-specific resources that are in src/.
The resource system is not yet used for anything; this will be added
in later commits.
2016-04-21 15:54:18 +00:00
|
|
|
|
|
|
|
function(add_resource name)
|
|
|
|
set(source ${CMAKE_CURRENT_SOURCE_DIR}/${name})
|
Use the same code for loading resources in all executables.
All of our executables need resources; e.g. the vector font is
a resource and it is necessary for generation. Before this commit,
the GUI executable loaded the resources in a nice way, and everything
else did it in a very ad-hoc, fragile way.
After this commit, all executables are placed in <build>/bin and
follow the same algorithm:
* On Windows, resources are compiled and linked into every
executable.
* On Linux, resources are copied into <build>/res (which is
tried first) and <prefix>/share/solvespace (which is tried
second).
* On macOS, resources are copied into <build>/res (which is
tried first) and <build>/bin/solvespace.app/Contents/Resources
(which is tried second).
In practice this means that we can add as many executables as we want
without duplicating lots of code. In addition, on macOS, we can
place supplementary executables into the bundle, and they can use
resources from the bundle transparently.
2016-11-28 04:16:18 +00:00
|
|
|
set(target_app ${app_resource_dir}/${name})
|
|
|
|
set(target_cli ${cli_resource_dir}/${name})
|
|
|
|
set(resource_list "${resource_list};${target_app};${target_cli}" PARENT_SCOPE)
|
Implement a resource system.
Currently, icons, fonts, etc are converted to C structures at compile
time and are hardcoded to the binary. This presents several problems:
* Cross-compilation is complicated. Right now, it is necessary
to be able to run executables for the target platform; this
happens to work with wine-binfmt installed, but is rather ugly.
* Icons can only have one resolution. On OS X, modern software is
expected to take advantage of high-DPI ("Retina") screens and
use so-called @2x assets when ran in high-DPI mode.
* Localization is complicated. Win32 and OS X provide built-in
support for loading the resource appropriate for the user's
locale.
* Embedding strings can only be done as raw strings, using C++'s
R"(...)" literals. This precludes embedding sizable strings,
e.g. JavaScript libraries as used in Three.js export, and makes
git history less useful. Not embedding the libraries means we
have to rely on external CDNs, which requires an Internet
connection and adds a glaring point of failure.
* Linux distribution guidelines are violated. All architecture-
independent data, especially large data such as fonts, is
expected to be in /usr/share, not in the binary.
* Customization is impossible without recompilation. Minor
modifications like adding a few missing vector font characters
or adjusting localization require a complete development
environment, which is unreasonable to expect from users of
a mechanical CAD.
As such, this commit adds a resource system that bundles (and
sometimes builds) resources with the executable. Where they go is
platform-dependent:
* on Win32: into resources of the executable, which allows us to
keep distributing one file;
* on OS X: into the app bundle;
* on other *nix: into /usr/share/solvespace/ or ../res/ (relative
to the executable path), the latter allowing us to run freshly
built executables without installation.
It also subsides the platform-specific resources that are in src/.
The resource system is not yet used for anything; this will be added
in later commits.
2016-04-21 15:54:18 +00:00
|
|
|
|
Use the same code for loading resources in all executables.
All of our executables need resources; e.g. the vector font is
a resource and it is necessary for generation. Before this commit,
the GUI executable loaded the resources in a nice way, and everything
else did it in a very ad-hoc, fragile way.
After this commit, all executables are placed in <build>/bin and
follow the same algorithm:
* On Windows, resources are compiled and linked into every
executable.
* On Linux, resources are copied into <build>/res (which is
tried first) and <prefix>/share/solvespace (which is tried
second).
* On macOS, resources are copied into <build>/res (which is
tried first) and <build>/bin/solvespace.app/Contents/Resources
(which is tried second).
In practice this means that we can add as many executables as we want
without duplicating lots of code. In addition, on macOS, we can
place supplementary executables into the bundle, and they can use
resources from the bundle transparently.
2016-11-28 04:16:18 +00:00
|
|
|
get_filename_component(target_app_dir ${target_app} DIRECTORY)
|
|
|
|
get_filename_component(target_cli_dir ${target_cli} DIRECTORY)
|
Implement a resource system.
Currently, icons, fonts, etc are converted to C structures at compile
time and are hardcoded to the binary. This presents several problems:
* Cross-compilation is complicated. Right now, it is necessary
to be able to run executables for the target platform; this
happens to work with wine-binfmt installed, but is rather ugly.
* Icons can only have one resolution. On OS X, modern software is
expected to take advantage of high-DPI ("Retina") screens and
use so-called @2x assets when ran in high-DPI mode.
* Localization is complicated. Win32 and OS X provide built-in
support for loading the resource appropriate for the user's
locale.
* Embedding strings can only be done as raw strings, using C++'s
R"(...)" literals. This precludes embedding sizable strings,
e.g. JavaScript libraries as used in Three.js export, and makes
git history less useful. Not embedding the libraries means we
have to rely on external CDNs, which requires an Internet
connection and adds a glaring point of failure.
* Linux distribution guidelines are violated. All architecture-
independent data, especially large data such as fonts, is
expected to be in /usr/share, not in the binary.
* Customization is impossible without recompilation. Minor
modifications like adding a few missing vector font characters
or adjusting localization require a complete development
environment, which is unreasonable to expect from users of
a mechanical CAD.
As such, this commit adds a resource system that bundles (and
sometimes builds) resources with the executable. Where they go is
platform-dependent:
* on Win32: into resources of the executable, which allows us to
keep distributing one file;
* on OS X: into the app bundle;
* on other *nix: into /usr/share/solvespace/ or ../res/ (relative
to the executable path), the latter allowing us to run freshly
built executables without installation.
It also subsides the platform-specific resources that are in src/.
The resource system is not yet used for anything; this will be added
in later commits.
2016-04-21 15:54:18 +00:00
|
|
|
add_custom_command(
|
Use the same code for loading resources in all executables.
All of our executables need resources; e.g. the vector font is
a resource and it is necessary for generation. Before this commit,
the GUI executable loaded the resources in a nice way, and everything
else did it in a very ad-hoc, fragile way.
After this commit, all executables are placed in <build>/bin and
follow the same algorithm:
* On Windows, resources are compiled and linked into every
executable.
* On Linux, resources are copied into <build>/res (which is
tried first) and <prefix>/share/solvespace (which is tried
second).
* On macOS, resources are copied into <build>/res (which is
tried first) and <build>/bin/solvespace.app/Contents/Resources
(which is tried second).
In practice this means that we can add as many executables as we want
without duplicating lots of code. In addition, on macOS, we can
place supplementary executables into the bundle, and they can use
resources from the bundle transparently.
2016-11-28 04:16:18 +00:00
|
|
|
OUTPUT ${target_app} ${target_cli}
|
|
|
|
COMMAND ${CMAKE_COMMAND} -E make_directory ${target_app_dir}
|
|
|
|
COMMAND ${CMAKE_COMMAND} -E copy ${source} ${target_app}
|
|
|
|
COMMAND ${CMAKE_COMMAND} -E make_directory ${target_cli_dir}
|
|
|
|
COMMAND ${CMAKE_COMMAND} -E copy ${source} ${target_cli}
|
Implement a resource system.
Currently, icons, fonts, etc are converted to C structures at compile
time and are hardcoded to the binary. This presents several problems:
* Cross-compilation is complicated. Right now, it is necessary
to be able to run executables for the target platform; this
happens to work with wine-binfmt installed, but is rather ugly.
* Icons can only have one resolution. On OS X, modern software is
expected to take advantage of high-DPI ("Retina") screens and
use so-called @2x assets when ran in high-DPI mode.
* Localization is complicated. Win32 and OS X provide built-in
support for loading the resource appropriate for the user's
locale.
* Embedding strings can only be done as raw strings, using C++'s
R"(...)" literals. This precludes embedding sizable strings,
e.g. JavaScript libraries as used in Three.js export, and makes
git history less useful. Not embedding the libraries means we
have to rely on external CDNs, which requires an Internet
connection and adds a glaring point of failure.
* Linux distribution guidelines are violated. All architecture-
independent data, especially large data such as fonts, is
expected to be in /usr/share, not in the binary.
* Customization is impossible without recompilation. Minor
modifications like adding a few missing vector font characters
or adjusting localization require a complete development
environment, which is unreasonable to expect from users of
a mechanical CAD.
As such, this commit adds a resource system that bundles (and
sometimes builds) resources with the executable. Where they go is
platform-dependent:
* on Win32: into resources of the executable, which allows us to
keep distributing one file;
* on OS X: into the app bundle;
* on other *nix: into /usr/share/solvespace/ or ../res/ (relative
to the executable path), the latter allowing us to run freshly
built executables without installation.
It also subsides the platform-specific resources that are in src/.
The resource system is not yet used for anything; this will be added
in later commits.
2016-04-21 15:54:18 +00:00
|
|
|
COMMENT "Copying resource ${name}"
|
|
|
|
DEPENDS ${source}
|
|
|
|
VERBATIM)
|
|
|
|
endfunction()
|
|
|
|
|
|
|
|
function(add_xib name)
|
|
|
|
set(source ${CMAKE_CURRENT_SOURCE_DIR}/${name})
|
|
|
|
get_filename_component(basename ${name} NAME_WE)
|
|
|
|
set(target ${app_resource_dir}/${basename}.nib)
|
|
|
|
set(resource_list "${resource_list};${target}" PARENT_SCOPE)
|
|
|
|
|
|
|
|
add_custom_command(
|
|
|
|
OUTPUT ${target}
|
|
|
|
COMMAND ${CMAKE_COMMAND} -E make_directory ${app_resource_dir}
|
|
|
|
COMMAND ibtool --errors --warnings --notices --output-format human-readable-text
|
|
|
|
--compile ${target} ${source}
|
|
|
|
COMMENT "Building Interface Builder file ${name}"
|
|
|
|
DEPENDS ${source}
|
|
|
|
VERBATIM)
|
|
|
|
endfunction()
|
|
|
|
|
|
|
|
function(add_iconset name)
|
|
|
|
set(source ${CMAKE_CURRENT_SOURCE_DIR}/${name})
|
|
|
|
get_filename_component(basename ${name} NAME_WE)
|
|
|
|
set(target ${app_resource_dir}/${basename}.icns)
|
|
|
|
set(resource_list "${resource_list};${target}" PARENT_SCOPE)
|
|
|
|
|
|
|
|
add_custom_command(
|
|
|
|
OUTPUT ${target}
|
|
|
|
COMMAND ${CMAKE_COMMAND} -E make_directory ${app_resource_dir}
|
|
|
|
COMMAND iconutil -c icns -o ${target} ${source}
|
|
|
|
COMMENT "Building icon set ${name}"
|
|
|
|
DEPENDS ${source}
|
|
|
|
VERBATIM)
|
|
|
|
endfunction()
|
|
|
|
else() # Unix
|
|
|
|
include(GNUInstallDirs)
|
|
|
|
|
|
|
|
set(app_resource_dir ${CMAKE_BINARY_DIR}/res)
|
|
|
|
|
|
|
|
function(add_resource name)
|
|
|
|
set(source ${CMAKE_CURRENT_SOURCE_DIR}/${name})
|
|
|
|
set(target ${app_resource_dir}/${name})
|
|
|
|
set(resource_list "${resource_list};${target}" PARENT_SCOPE)
|
|
|
|
|
|
|
|
get_filename_component(target_dir ${target} DIRECTORY)
|
|
|
|
add_custom_command(
|
|
|
|
OUTPUT ${target}
|
|
|
|
COMMAND ${CMAKE_COMMAND} -E make_directory ${target_dir}
|
|
|
|
COMMAND ${CMAKE_COMMAND} -E copy ${source} ${target}
|
|
|
|
COMMENT "Copying resource ${name}"
|
|
|
|
DEPENDS ${source}
|
|
|
|
VERBATIM)
|
|
|
|
|
|
|
|
get_filename_component(name_dir ${name} DIRECTORY)
|
|
|
|
install(FILES ${source}
|
|
|
|
DESTINATION ${CMAKE_INSTALL_DATAROOTDIR}/solvespace/${name_dir})
|
|
|
|
endfunction()
|
|
|
|
endif()
|
|
|
|
|
2016-04-22 13:35:22 +00:00
|
|
|
function(add_resources)
|
|
|
|
foreach(name ${ARGN})
|
|
|
|
add_resource(${name})
|
|
|
|
set(resource_list "${resource_list}" PARENT_SCOPE)
|
|
|
|
endforeach()
|
|
|
|
endfunction()
|
|
|
|
|
Implement a resource system.
Currently, icons, fonts, etc are converted to C structures at compile
time and are hardcoded to the binary. This presents several problems:
* Cross-compilation is complicated. Right now, it is necessary
to be able to run executables for the target platform; this
happens to work with wine-binfmt installed, but is rather ugly.
* Icons can only have one resolution. On OS X, modern software is
expected to take advantage of high-DPI ("Retina") screens and
use so-called @2x assets when ran in high-DPI mode.
* Localization is complicated. Win32 and OS X provide built-in
support for loading the resource appropriate for the user's
locale.
* Embedding strings can only be done as raw strings, using C++'s
R"(...)" literals. This precludes embedding sizable strings,
e.g. JavaScript libraries as used in Three.js export, and makes
git history less useful. Not embedding the libraries means we
have to rely on external CDNs, which requires an Internet
connection and adds a glaring point of failure.
* Linux distribution guidelines are violated. All architecture-
independent data, especially large data such as fonts, is
expected to be in /usr/share, not in the binary.
* Customization is impossible without recompilation. Minor
modifications like adding a few missing vector font characters
or adjusting localization require a complete development
environment, which is unreasonable to expect from users of
a mechanical CAD.
As such, this commit adds a resource system that bundles (and
sometimes builds) resources with the executable. Where they go is
platform-dependent:
* on Win32: into resources of the executable, which allows us to
keep distributing one file;
* on OS X: into the app bundle;
* on other *nix: into /usr/share/solvespace/ or ../res/ (relative
to the executable path), the latter allowing us to run freshly
built executables without installation.
It also subsides the platform-specific resources that are in src/.
The resource system is not yet used for anything; this will be added
in later commits.
2016-04-21 15:54:18 +00:00
|
|
|
# Second, register all resources.
|
2016-04-21 16:59:13 +00:00
|
|
|
if(WIN32)
|
2016-12-04 20:16:05 +00:00
|
|
|
add_resource(win32/icon.ico 4000 ICON)
|
2018-07-12 19:29:44 +00:00
|
|
|
add_resource(win32/manifest.xml 1 RT_MANIFEST)
|
2016-04-21 17:15:38 +00:00
|
|
|
elseif(APPLE)
|
2016-04-21 17:36:20 +00:00
|
|
|
add_iconset (cocoa/AppIcon.iconset)
|
|
|
|
add_xib (cocoa/MainMenu.xib)
|
|
|
|
add_xib (cocoa/SaveFormatAccessory.xib)
|
2016-04-21 17:15:38 +00:00
|
|
|
else()
|
2016-05-18 17:23:14 +00:00
|
|
|
add_resource(freedesktop/solvespace-48x48.png)
|
|
|
|
|
2019-05-11 15:36:54 +00:00
|
|
|
if(FLATPAK)
|
|
|
|
configure_file(
|
|
|
|
${CMAKE_CURRENT_SOURCE_DIR}/freedesktop/solvespace-flatpak.desktop.in
|
|
|
|
${CMAKE_CURRENT_BINARY_DIR}/freedesktop/solvespace-flatpak.desktop)
|
|
|
|
install(FILES ${CMAKE_CURRENT_BINARY_DIR}/freedesktop/solvespace-flatpak.desktop
|
|
|
|
DESTINATION ${CMAKE_INSTALL_DATAROOTDIR}/applications
|
|
|
|
RENAME com.solvespace.SolveSpace.desktop)
|
|
|
|
|
|
|
|
install(FILES freedesktop/solvespace-flatpak-mime.xml
|
|
|
|
DESTINATION ${CMAKE_INSTALL_DATAROOTDIR}/mime/packages
|
|
|
|
RENAME com.solvespace.SolveSpace-slvs.xml)
|
|
|
|
|
2019-06-14 17:20:14 +00:00
|
|
|
install(FILES freedesktop/solvespace-scalable.svg
|
|
|
|
DESTINATION ${CMAKE_INSTALL_DATAROOTDIR}/icons/hicolor/scalable/apps
|
|
|
|
RENAME com.solvespace.SolveSpace.svg)
|
|
|
|
install(FILES freedesktop/solvespace-scalable.svg
|
|
|
|
DESTINATION ${CMAKE_INSTALL_DATAROOTDIR}/icons/hicolor/scalable/mimetypes
|
|
|
|
RENAME com.solvespace.SolveSpace.svg)
|
|
|
|
|
2019-05-11 15:36:54 +00:00
|
|
|
foreach(SIZE 16x16 24x24 32x32 48x48)
|
|
|
|
install(FILES freedesktop/solvespace-${SIZE}.png
|
|
|
|
DESTINATION ${CMAKE_INSTALL_DATAROOTDIR}/icons/hicolor/${SIZE}/apps
|
|
|
|
RENAME com.solvespace.SolveSpace.png)
|
|
|
|
install(FILES freedesktop/solvespace-${SIZE}.png
|
|
|
|
DESTINATION ${CMAKE_INSTALL_DATAROOTDIR}/icons/hicolor/${SIZE}/mimetypes
|
|
|
|
RENAME com.solvespace.SolveSpace.png)
|
|
|
|
endforeach()
|
2019-09-11 10:12:53 +00:00
|
|
|
elseif(SNAP)
|
|
|
|
install(FILES ${CMAKE_CURRENT_SOURCE_DIR}/freedesktop/solvespace-snap.desktop
|
|
|
|
DESTINATION /
|
|
|
|
RENAME solvespace.desktop)
|
|
|
|
|
|
|
|
# snapd does not support registering new mime types
|
|
|
|
|
|
|
|
install(FILES freedesktop/solvespace-scalable.svg
|
|
|
|
DESTINATION /meta/icons/hicolor/scalable/apps
|
|
|
|
RENAME snap.solvespace.svg)
|
|
|
|
|
|
|
|
foreach(SIZE 16x16 24x24 32x32 48x48)
|
|
|
|
install(FILES freedesktop/solvespace-${SIZE}.png
|
|
|
|
DESTINATION /meta/icons/hicolor/${SIZE}/apps
|
|
|
|
RENAME snap.solvespace.png)
|
|
|
|
endforeach()
|
2019-05-11 15:36:54 +00:00
|
|
|
else()
|
|
|
|
configure_file(
|
|
|
|
${CMAKE_CURRENT_SOURCE_DIR}/freedesktop/solvespace.desktop.in
|
|
|
|
${CMAKE_CURRENT_BINARY_DIR}/freedesktop/solvespace.desktop)
|
|
|
|
install(FILES ${CMAKE_CURRENT_BINARY_DIR}/freedesktop/solvespace.desktop
|
|
|
|
DESTINATION ${CMAKE_INSTALL_DATAROOTDIR}/applications)
|
|
|
|
|
|
|
|
install(FILES freedesktop/solvespace-mime.xml
|
|
|
|
DESTINATION ${CMAKE_INSTALL_DATAROOTDIR}/mime/packages
|
|
|
|
RENAME solvespace-slvs.xml)
|
2019-06-14 17:20:14 +00:00
|
|
|
|
|
|
|
install(FILES freedesktop/solvespace-scalable.svg
|
|
|
|
DESTINATION ${CMAKE_INSTALL_DATAROOTDIR}/icons/hicolor/scalable/apps
|
|
|
|
RENAME solvespace.svg)
|
|
|
|
install(FILES freedesktop/solvespace-scalable.svg
|
|
|
|
DESTINATION ${CMAKE_INSTALL_DATAROOTDIR}/icons/hicolor/scalable/mimetypes
|
|
|
|
RENAME application.x-solvespace.svg)
|
2019-05-11 15:36:54 +00:00
|
|
|
|
|
|
|
foreach(SIZE 16x16 24x24 32x32 48x48)
|
|
|
|
install(FILES freedesktop/solvespace-${SIZE}.png
|
|
|
|
DESTINATION ${CMAKE_INSTALL_DATAROOTDIR}/icons/hicolor/${SIZE}/apps
|
|
|
|
RENAME solvespace.png)
|
|
|
|
install(FILES freedesktop/solvespace-${SIZE}.png
|
|
|
|
DESTINATION ${CMAKE_INSTALL_DATAROOTDIR}/icons/hicolor/${SIZE}/mimetypes
|
|
|
|
RENAME application.x-solvespace.png)
|
|
|
|
endforeach()
|
|
|
|
|
|
|
|
foreach(SIZE 16x16 24x24 32x32 48x48)
|
|
|
|
install(FILES freedesktop/solvespace-${SIZE}.xpm
|
|
|
|
DESTINATION ${CMAKE_INSTALL_DATAROOTDIR}/pixmaps)
|
|
|
|
endforeach()
|
|
|
|
endif()
|
2016-04-21 16:59:13 +00:00
|
|
|
endif()
|
2016-04-22 13:35:22 +00:00
|
|
|
|
|
|
|
add_resources(
|
|
|
|
banner.txt
|
|
|
|
icons/graphics-window/angle.png
|
|
|
|
icons/graphics-window/arc.png
|
|
|
|
icons/graphics-window/assemble.png
|
|
|
|
icons/graphics-window/bezier.png
|
|
|
|
icons/graphics-window/circle.png
|
|
|
|
icons/graphics-window/construction.png
|
|
|
|
icons/graphics-window/equal.png
|
|
|
|
icons/graphics-window/extrude.png
|
|
|
|
icons/graphics-window/horiz.png
|
2016-11-29 16:49:20 +00:00
|
|
|
icons/graphics-window/image.png
|
2016-04-22 13:35:22 +00:00
|
|
|
icons/graphics-window/in3d.png
|
|
|
|
icons/graphics-window/lathe.png
|
|
|
|
icons/graphics-window/length.png
|
|
|
|
icons/graphics-window/line.png
|
|
|
|
icons/graphics-window/ontoworkplane.png
|
|
|
|
icons/graphics-window/other-supp.png
|
|
|
|
icons/graphics-window/parallel.png
|
|
|
|
icons/graphics-window/perpendicular.png
|
|
|
|
icons/graphics-window/pointonx.png
|
|
|
|
icons/graphics-window/point.png
|
|
|
|
icons/graphics-window/rectangle.png
|
|
|
|
icons/graphics-window/ref.png
|
|
|
|
icons/graphics-window/same-orientation.png
|
|
|
|
icons/graphics-window/sketch-in-3d.png
|
|
|
|
icons/graphics-window/sketch-in-plane.png
|
|
|
|
icons/graphics-window/step-rotate.png
|
|
|
|
icons/graphics-window/step-translate.png
|
|
|
|
icons/graphics-window/symmetric.png
|
|
|
|
icons/graphics-window/tangent-arc.png
|
|
|
|
icons/graphics-window/text.png
|
|
|
|
icons/graphics-window/trim.png
|
|
|
|
icons/graphics-window/vert.png
|
|
|
|
icons/text-window/constraint.png
|
2019-05-23 16:06:24 +00:00
|
|
|
icons/text-window/construction.png
|
2016-04-22 13:35:22 +00:00
|
|
|
icons/text-window/edges.png
|
|
|
|
icons/text-window/faces.png
|
2016-08-13 09:02:12 +00:00
|
|
|
icons/text-window/occluded-visible.png
|
|
|
|
icons/text-window/occluded-stippled.png
|
|
|
|
icons/text-window/occluded-invisible.png
|
2016-04-22 13:35:22 +00:00
|
|
|
icons/text-window/mesh.png
|
|
|
|
icons/text-window/normal.png
|
|
|
|
icons/text-window/outlines.png
|
|
|
|
icons/text-window/point.png
|
|
|
|
icons/text-window/shaded.png
|
2016-04-23 04:37:42 +00:00
|
|
|
icons/text-window/workplane.png
|
2017-01-04 15:39:27 +00:00
|
|
|
locales.txt
|
2018-07-20 04:40:09 +00:00
|
|
|
locales/de_DE.po
|
2017-01-04 15:39:27 +00:00
|
|
|
locales/en_US.po
|
2018-07-14 18:21:03 +00:00
|
|
|
locales/fr_FR.po
|
2017-01-07 16:37:23 +00:00
|
|
|
locales/uk_UA.po
|
2017-04-18 15:33:11 +00:00
|
|
|
locales/ru_RU.po
|
2020-09-28 05:15:34 +00:00
|
|
|
locales/zh_CN.po
|
2016-04-23 04:37:42 +00:00
|
|
|
fonts/unifont.hex.gz
|
|
|
|
fonts/private/0-check-false.png
|
|
|
|
fonts/private/1-check-true.png
|
|
|
|
fonts/private/2-radio-false.png
|
|
|
|
fonts/private/3-radio-true.png
|
|
|
|
fonts/private/4-stipple-dot.png
|
|
|
|
fonts/private/5-stipple-dash-long.png
|
|
|
|
fonts/private/6-stipple-dash.png
|
2016-04-24 22:35:23 +00:00
|
|
|
fonts/private/7-stipple-zigzag.png
|
2016-05-18 11:44:32 +00:00
|
|
|
fonts/unicode.lff.gz
|
2018-07-12 18:58:44 +00:00
|
|
|
fonts/BitstreamVeraSans-Roman-builtin.ttf
|
2016-06-30 15:54:35 +00:00
|
|
|
shaders/imesh.frag
|
|
|
|
shaders/imesh.vert
|
|
|
|
shaders/imesh_point.frag
|
|
|
|
shaders/imesh_point.vert
|
|
|
|
shaders/imesh_tex.frag
|
|
|
|
shaders/imesh_texa.frag
|
|
|
|
shaders/imesh_tex.vert
|
|
|
|
shaders/mesh.frag
|
|
|
|
shaders/mesh.vert
|
|
|
|
shaders/mesh_fill.frag
|
|
|
|
shaders/mesh_fill.vert
|
|
|
|
shaders/edge.frag
|
|
|
|
shaders/edge.vert
|
|
|
|
shaders/outline.vert
|
2016-05-18 11:44:32 +00:00
|
|
|
threejs/three-r76.js.gz
|
|
|
|
threejs/hammer-2.0.8.js.gz
|
|
|
|
threejs/SolveSpaceControls.js)
|
Implement a resource system.
Currently, icons, fonts, etc are converted to C structures at compile
time and are hardcoded to the binary. This presents several problems:
* Cross-compilation is complicated. Right now, it is necessary
to be able to run executables for the target platform; this
happens to work with wine-binfmt installed, but is rather ugly.
* Icons can only have one resolution. On OS X, modern software is
expected to take advantage of high-DPI ("Retina") screens and
use so-called @2x assets when ran in high-DPI mode.
* Localization is complicated. Win32 and OS X provide built-in
support for loading the resource appropriate for the user's
locale.
* Embedding strings can only be done as raw strings, using C++'s
R"(...)" literals. This precludes embedding sizable strings,
e.g. JavaScript libraries as used in Three.js export, and makes
git history less useful. Not embedding the libraries means we
have to rely on external CDNs, which requires an Internet
connection and adds a glaring point of failure.
* Linux distribution guidelines are violated. All architecture-
independent data, especially large data such as fonts, is
expected to be in /usr/share, not in the binary.
* Customization is impossible without recompilation. Minor
modifications like adding a few missing vector font characters
or adjusting localization require a complete development
environment, which is unreasonable to expect from users of
a mechanical CAD.
As such, this commit adds a resource system that bundles (and
sometimes builds) resources with the executable. Where they go is
platform-dependent:
* on Win32: into resources of the executable, which allows us to
keep distributing one file;
* on OS X: into the app bundle;
* on other *nix: into /usr/share/solvespace/ or ../res/ (relative
to the executable path), the latter allowing us to run freshly
built executables without installation.
It also subsides the platform-specific resources that are in src/.
The resource system is not yet used for anything; this will be added
in later commits.
2016-04-21 15:54:18 +00:00
|
|
|
|
|
|
|
# Third, distribute the resources.
|
|
|
|
add_custom_target(resources
|
|
|
|
DEPENDS ${resource_list})
|
|
|
|
if(WIN32)
|
|
|
|
set_property(TARGET resources PROPERTY EXTRA_SOURCES ${rc_file})
|
|
|
|
endif()
|