This allows people to use the base directory of cross-compiled
dependencies (typically our dependencies.zip file), rather than always
having to specify the actual include directory.
This addition allows external cmake modules to include the same modules
that are commonly distributed with the main obs-studio repo: things like
FFmpeg, curl, etc.
This cmake module adds various cmake functions used for generating obs
plugins. This currently may not fully support linux; this may require
more changes on linux due to the nature of the file structure linux
uses.
Fixes issues using DepsPath(32|64), was using ${lib_suffix} instead of
${_lib_suffix} so 32/64-sepcific directories wouldn't work properly.
Also the DepsPath environment/cmake variable wasn't specified for the
library search.
Also added the same dependency search paths for libfdk (if someone wants
to use it on windows for whatever reason)
Since we rely on the dynamic linker to find the library for us via
dlopen(), we need to have DL_OPENGL be .so.N, not the full library
filename, as ldconfig doesn't cache the full filename
Use of TARGET_SONAME_FILE requires the library to be marked as SHARED,
not MODULE
This closes pull request #370
Because libobs-opengl is a public library, it's customary to have SONAME
embedded in the library file. Also remove the prefix override and
remove the prefixing "lib" from the output name. This also requires us
to pass the library file name to dlopen invocations.
Copying this binary is kind of unnecessary because it's something that
everyone has as long as they update DirectX, and isn't something we can
distribute because it's a Microsoft DLL.
I actually did this because it makes it a bit easier to use with a
build from cross-compiled windows FFMpeg/x264 DLLs. When compiling on
linux I just have it compile to a custom prefix directory for the
specific windows arch, then I just copy the arch dir back to my windows
HD when complete. Adding this to the cmake allows me to use the compile
arch directories directly without modification.
This will hopefully help deal with a particular issue where the program
may go to sleep if it hasn't received input from the user for long
periods, or if a game is running in fullscreen mode apparently.
This uses fontconfig for looking up font files for freetype to use on
both linux and mac. It's apparently a bit more optimal and prevents us
from having to worry about the load time on the mac version as well.
Refactored and moved all the old code to the find-font-windows.c file,
as it's no longer used on anything but windows.
On fedora, the freetype cmake module would not find the correct
location. This is because it wasn't using the pkg-cofig include
directory, which is different from the main ft2build.h header directory
(which is /usr/include).
This modification may be a good thing to do on all the cmake packages,
actually. Currently, they all just search for the location of a
specific header, and ignore the pkg-config includes if they find it in
specific hint locations.
This changes the font plugin from using a font file to using a specific
installed system font, which is searched for on each specific system and
associated with the font file. It now uses a font property instead of a
path property, and font size has been removed because the font property
now handles that.
When the module is first loaded, it will build up a list of system fonts
in order to be usable by Freetype. It was quite painful to program this
because font files can contain multiple localized versions of their face
names, and then there was the issue where windows likes to mangle
custom style types to the font name. Regardless, it all seems to have
worked out pretty well.
Minor issues:
- Truetype/Opentype fonts sometimes do not automatically have
italic and/or bold styles available, it seems that the system applies
transformations manually in those cases. We don't do this yet,
however, so right now a user might select a font with italic/bold
only to discover that italic/bold doesn't always work. Not entirely
sure what to do about this yet. There's probably a freetype function
to do something like that somehow,
This also requires that iconv be used for non-windows systems to be able
to look up localized font names within font files. Windows will use
the win32 API and code page IDs to translate font names.