This gets rid of a prefix inside our build dir, and uses DESTDIR
when installing the content. This way, the install directory
can be reused for further packaging introduced in the next commits.
This enables us to just run the vlc executable from an installed
directory like on any other POSIX installation. All modules should
work, apart the macOS interface module which requires the bundle
structure.
For posix-style installations, use the defined directories
for libraries and data.
With that, running vlc from the install dirs works fine in principle.
What is left to do currently is to adapt the RPATH to find the
libvlc libraries.
This prevents these executables from linking to a shared
libssp-0.dll if both a static and shared version is available
of this library.
Since these refer to the dynamically linked libvlc via libvlc.la,
it will still pick up the correct shared version of those, instead
of refusing to link to a dynamic library (as it does for any
library specified via -l<name>).
The same use of -Wc,-static is present in a few other Makefile.am
already.
pkglibexecdir is the pseudo-directory for internal executables.
vlc-qt-check already uses that. Indeed, PROGRAMS and SCRIPTS targets
are not allowed by automake in pkglibdir.
(libexecdir can be set to '${libdir}' in configure if/when the
distinction is unwanted.)
This needed on Windows as LoadLibraryEx doesn't like relative pathes and thus
building on Windows doesn't go to the end.
The resulting pathes in plugins.dat are still relative and so are the ones
resulting from `make package-win-common` that can be distributed.
Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>
RT_MANIFEST is a macro that wasn't being substituted
2 was the magic number that corresponds to
ISOLATIONAWARE_MANIFEST_RESOURCE_ID, which should be used for DLLs.
Instead, use CREATEPROCESS_MANIFEST_RESOURCE_ID as we are creating a
process