shaba/virt-viewer
1
0
Fork 0
mirror of https://gitlab.com/virt-viewer/virt-viewer.git synced 2025-01-06 13:17:45 +03:00
Code Issues Projects Releases Wiki Activity
ac316905b4
virt-viewer/data/Makefile.am

108 lines
2.8 KiB
Makefile
Raw Normal View History

Register remote-viewer mime handling Unfortunately, I don't see yet how we could avoid the browser dialog asking which application to open. On Firefox, each user has a mimeTypes.rdf, but we can't really modify it..
2013-01-21 18:09:37 +04:00
NULL =
CLEANFILES =
Set MANUFACTURER env variable when running wixl The MANUFACTURER env variable is mandatory since it is used in the data files. wixl will exit with parser error if it is not set Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-05-01 13:21:25 +04:00
MANUFACTURER = Virt Manager Project
Add virt-viewer.nsis Use ${DESTDIR} variable and @prefix@ to look for files. Can't easily be generated, it has too much customization.
2012-01-27 17:51:36 +04:00
EXTRA_DIST = \
win: add virt-viewer.msi build rule In order to build the MSI, you will need msitools: http://ftp.gnome.org/pub/GNOME/sources/msitools/ The MANUFACTURER environment variable is mandatory and should be set to the manufacturer/author of the MSI build.
2013-01-16 20:27:58 +04:00
virt-viewer.wxs.in \
po: provide custom make rules for po file management Historically we have relied on intltool to install a standard po/Makefile.in.in which has very limited scope for customization. intltool is deprecated in favour of standard gettextize tools, but these share the same disadvantages. Writing make rules for po file management is no more difficult than any other rules virt-viewer has, so stop using intltool and don't use gettextize ether. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-02-20 18:19:43 +03:00
gettext/its/mime.its \
gettext/its/mime.loc \
Add virt-viewer.nsis Use ${DESTDIR} variable and @prefix@ to look for files. Can't easily be generated, it has too much customization.
2012-01-27 17:51:36 +04:00
$(NULL)
build-sys: use git.mk to generate gitignore This makefile is just fantastic, it forces you into good practices, support various build targets (my windows builddir ignore the right files etc..) The more I use it, the more I like it.
2012-03-30 04:43:26 +04:00
po: provide custom make rules for po file management Historically we have relied on intltool to install a standard po/Makefile.in.in which has very limited scope for customization. intltool is deprecated in favour of standard gettextize tools, but these share the same disadvantages. Writing make rules for po file management is no more difficult than any other rules virt-viewer has, so stop using intltool and don't use gettextize ether. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-02-20 18:19:43 +03:00
PO_FILES = $(wildcard $(srcdir)/../po/*.po)
build-sys: regenerate spec files when they change
2013-04-03 16:02:01 +04:00
# this make sure those files are regenerated when they change
# (in maintainer-mode)
msi: Depend on mingw-adwaita-icon-theme Instead of maintain a file which includes every single icon that we use from adwaita-icon-theme (adwaita-icons-needed.wxi.in), let's depend on mingw-adwaita-icon-theme directly. It reduces considerably the maintainability and the risk to have missing icons. Although, the size of the final binary gets increased from ~35MB to ~50MB. Resolves: rhbz#1301064 Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com> Acked-by: Christophe Fergeau <cfergeau@redhat.com>
2016-04-26 15:36:57 +03:00
all-local: virt-viewer.wxs
build-sys: regenerate spec files when they change
2013-04-03 16:02:01 +04:00
nsis: add deps.txt file in installer This helps track package version that were used during the build of Windows installer. It's not ideal, but make up the lack of package management on windows
2012-06-05 23:30:18 +04:00
if OS_WIN32
win: add virt-viewer.msi build rule In order to build the MSI, you will need msitools: http://ftp.gnome.org/pub/GNOME/sources/msitools/ The MANUFACTURER environment variable is mandatory and should be set to the manufacturer/author of the MSI build.
2013-01-16 20:27:58 +04:00
msi: use libvirt conditionally Only include libvirt as dep when it's explicitly done in the configure.
2014-12-17 08:16:41 +03:00
if HAVE_LIBVIRT
HaveLibvirt = True
else
HaveLibvirt = False
endif
msi: use libgovirt conditionally Only include libgovirt as dep when it's explicitly done in the configure.
2014-12-17 08:21:33 +03:00
if HAVE_OVIRT
HaveOVirt = True
else
HaveOVirt = False
endif
msi: use spice-gtk conditionally Only include spice-gtk as dep when it's explicitly done in the configure.
2014-12-17 08:25:32 +03:00
if HAVE_SPICE_GTK
HaveSpiceGtk = True
else
HaveSpiceGtk = False
endif
msi: use gtk-vnc conditionally Only include gtk-vnc as dep when it's explicitly done in the configure.
2014-12-17 08:29:21 +03:00
if HAVE_GTK_VNC
HaveGtkVnc = True
else
HaveGtkVnc = False
endif
msi: record full build environment in MSI installer For proper compliance with the GPL and other licenses we need to be clear about exactly what toolchain and dependent packages we used in order to build the MSI installer we distribute. Historically we've done this by including a "deps.txt" file which provides a list of all the mingw{32,64}-* RPMs on the host system. This is not sufficient information, however, because the build system will in fact use various native packages too from the toolchain too, notably including any program run by "configure" which covers various shell utilities, and pkg-config, and then of course make & msitools itself. Rather than try to figure out which subset of host RPMs are used, just list every single host RPM that is installed. A key implication of this is that formal release builds should always be done in a pristine build root populated with the minimal content required for the build. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-02-15 13:38:41 +03:00
buildenv.txt:
$(AM_V_GEN)rpm -qa | sort | unix2dos > $@
nsis: add deps.txt file in installer This helps track package version that were used during the build of Windows installer. It's not ideal, but make up the lack of package management on windows
2012-06-05 23:30:18 +04:00
msi: record full build environment in MSI installer For proper compliance with the GPL and other licenses we need to be clear about exactly what toolchain and dependent packages we used in order to build the MSI installer we distribute. Historically we've done this by including a "deps.txt" file which provides a list of all the mingw{32,64}-* RPMs on the host system. This is not sufficient information, however, because the build system will in fact use various native packages too from the toolchain too, notably including any program run by "configure" which covers various shell utilities, and pkg-config, and then of course make & msitools itself. Rather than try to figure out which subset of host RPMs are used, just list every single host RPM that is installed. A key implication of this is that formal release builds should always be done in a pristine build root populated with the minimal content required for the build. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-02-15 13:38:41 +03:00
virt-viewer-$(WIXL_ARCH)-$(VERSION).msi: virt-viewer.wxs buildenv.txt
msi: build correct 64-bit msi
2013-04-12 16:45:56 +04:00
$(AM_V_GEN)DESTDIR=`mktemp -d` && \
make -C $(top_builddir) install DESTDIR=$$DESTDIR >/dev/null && \
find $$DESTDIR | wixl-heat -p $$DESTDIR$(prefix)/ \
--component-group CG.virt-viewer --var var.DESTDIR \
--directory-ref=INSTALLDIR > virt-viewer-files.wxs && \
Set MANUFACTURER env variable when running wixl The MANUFACTURER env variable is mandatory since it is used in the data files. wixl will exit with parser error if it is not set Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2013-05-01 13:21:25 +04:00
MANUFACTURER="$(MANUFACTURER)" wixl -D SourceDir=$(prefix) \
msi: build correct 64-bit msi
2013-04-12 16:45:56 +04:00
-D DESTDIR=$$DESTDIR$(prefix) \
msi: use spice-gtk conditionally Only include spice-gtk as dep when it's explicitly done in the configure.
2014-12-17 08:25:32 +03:00
-D HaveSpiceGtk=$(HaveSpiceGtk) \
msi: use gtk-vnc conditionally Only include gtk-vnc as dep when it's explicitly done in the configure.
2014-12-17 08:29:21 +03:00
-D HaveGtkVnc=$(HaveGtkVnc) \
msi: use libvirt conditionally Only include libvirt as dep when it's explicitly done in the configure.
2014-12-17 08:16:41 +03:00
-D HaveLibvirt=$(HaveLibvirt) \
msi: use libgovirt conditionally Only include libgovirt as dep when it's explicitly done in the configure.
2014-12-17 08:21:33 +03:00
-D HaveOVirt=$(HaveOVirt) \
msi: build correct 64-bit msi
2013-04-12 16:45:56 +04:00
--arch $(WIXL_ARCH) \
-o $@ \
$< virt-viewer-files.wxs && \
win: add virt-viewer.msi build rule In order to build the MSI, you will need msitools: http://ftp.gnome.org/pub/GNOME/sources/msitools/ The MANUFACTURER environment variable is mandatory and should be set to the manufacturer/author of the MSI build.
2013-01-16 20:27:58 +04:00
rm -rf $$DESTDIR virt-viewer-files.wxs
msi: build correct 64-bit msi
2013-04-12 16:45:56 +04:00
msi: virt-viewer-$(WIXL_ARCH)-$(VERSION).msi
Don't define the same make target/variables twice The NSIS patches defined the .PHONY target twice and also defined CLEANFILES twice
2013-02-13 19:15:46 +04:00
CLEANFILES += \
msi: record full build environment in MSI installer For proper compliance with the GPL and other licenses we need to be clear about exactly what toolchain and dependent packages we used in order to build the MSI installer we distribute. Historically we've done this by including a "deps.txt" file which provides a list of all the mingw{32,64}-* RPMs on the host system. This is not sufficient information, however, because the build system will in fact use various native packages too from the toolchain too, notably including any program run by "configure" which covers various shell utilities, and pkg-config, and then of course make & msitools itself. Rather than try to figure out which subset of host RPMs are used, just list every single host RPM that is installed. A key implication of this is that formal release builds should always be done in a pristine build root populated with the minimal content required for the build. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-02-15 13:38:41 +03:00
buildenv.txt \
msi: build correct 64-bit msi
2013-04-12 16:45:56 +04:00
virt-viewer-$(WIXL_ARCH)-$(VERSION).msi \
win: add virt-viewer.msi build rule In order to build the MSI, you will need msitools: http://ftp.gnome.org/pub/GNOME/sources/msitools/ The MANUFACTURER environment variable is mandatory and should be set to the manufacturer/author of the MSI build.
2013-01-16 20:27:58 +04:00
$(NULL)
Register remote-viewer mime handling Unfortunately, I don't see yet how we could avoid the browser dialog asking which application to open. On Firefox, each user has a mimeTypes.rdf, but we can't really modify it..
2013-01-21 18:09:37 +04:00
else #!WIN32
desktopdir = $(datadir)/applications
DESKTOPFILES = remote-viewer.desktop.in
desktop_DATA = $(DESKTOPFILES:.desktop.in=.desktop)
po: provide custom make rules for po file management Historically we have relied on intltool to install a standard po/Makefile.in.in which has very limited scope for customization. intltool is deprecated in favour of standard gettextize tools, but these share the same disadvantages. Writing make rules for po file management is no more difficult than any other rules virt-viewer has, so stop using intltool and don't use gettextize ether. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-02-20 18:19:43 +03:00
%.desktop: %.desktop.in $(PO_FILES)
$(AM_V_GEN)$(MSGFMT) --desktop --template $< -d $(top_srcdir)/po -o $@
Register remote-viewer mime handling Unfortunately, I don't see yet how we could avoid the browser dialog asking which application to open. On Firefox, each user has a mimeTypes.rdf, but we can't really modify it..
2013-01-21 18:09:37 +04:00
MIMEFILES = virt-viewer-mime.xml.in
mimedir = $(datadir)/mime/packages
mime_DATA = virt-viewer-mime.xml
po: provide custom make rules for po file management Historically we have relied on intltool to install a standard po/Makefile.in.in which has very limited scope for customization. intltool is deprecated in favour of standard gettextize tools, but these share the same disadvantages. Writing make rules for po file management is no more difficult than any other rules virt-viewer has, so stop using intltool and don't use gettextize ether. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-02-20 18:19:43 +03:00
%-mime.xml: %-mime.xml.in $(PO_FILES)
$(AM_V_GEN)GETTEXTDATADIR=$(srcdir)/gettext $(MSGFMT) --xml --template $< -d $(top_srcdir)/po -o $@
Register remote-viewer mime handling Unfortunately, I don't see yet how we could avoid the browser dialog asking which application to open. On Firefox, each user has a mimeTypes.rdf, but we can't really modify it..
2013-01-21 18:09:37 +04:00
package: Add appdata metadata for Gnome Software Adds metadata to be used with Gnome Software. Includes name, summary, description and a few screenshots of remote-viewer. Signed-off-by: Lukáš Venhoda <lvenhoda@redhat.com> Acked-by: Daniel P. Berrange <berrange@redhat.com> Acked-by: Fabiano Fidêncio <fidencio@redhat.com>
2016-06-27 18:20:54 +03:00
appdatadir = $(datadir)/appdata
APPDATAFILES = remote-viewer.appdata.xml.in
appdata_DATA = $(APPDATAFILES:.xml.in=.xml)
po: provide custom make rules for po file management Historically we have relied on intltool to install a standard po/Makefile.in.in which has very limited scope for customization. intltool is deprecated in favour of standard gettextize tools, but these share the same disadvantages. Writing make rules for po file management is no more difficult than any other rules virt-viewer has, so stop using intltool and don't use gettextize ether. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-02-20 18:19:43 +03:00
%.appdata.xml: %.appdata.xml.in $(PO_FILES)
$(AM_V_GEN)$(MSGFMT) --xml --template $< -d $(top_srcdir)/po -o $@
package: Add appdata metadata for Gnome Software Adds metadata to be used with Gnome Software. Includes name, summary, description and a few screenshots of remote-viewer. Signed-off-by: Lukáš Venhoda <lvenhoda@redhat.com> Acked-by: Daniel P. Berrange <berrange@redhat.com> Acked-by: Fabiano Fidêncio <fidencio@redhat.com>
2016-06-27 18:20:54 +03:00
Update shared mime database on install/uninstall remomte-viewer installs a file to $datadir/share/mime to register a mime-type for its .vv files. However, after installing this file, update-mime-database must be run in order to update the shared mime database. This commit (inspired by what Nautilus/planner are doing) adds what is needed for that. If the mime type is not correctly registered, gvfs-info console.vv will not return the correct mime type, and xdg-open console.vv will fail to start remote-viewer, and will fall back to running gedit as the .vv file is a text file. https://bugzilla.redhat.com/show_bug.cgi?id=1044209
2013-12-18 13:28:40 +04:00
install-data-hook:
if ENABLE_UPDATE_MIMEDB
@if $(AM_V_P); then set -x; else echo " INSTALL update-mime-database"; fi; \
$(UPDATE_MIME_DATABASE) "$(DESTDIR)$(datadir)/mime";
endif
uninstall-hook:
if ENABLE_UPDATE_MIMEDB
@if $(AM_V_P); then set -x; else echo " UNINSTALL update-mime-database"; fi; \
$(UPDATE_MIME_DATABASE) "$(DESTDIR)$(datadir)/mime";
endif
package: Add appdata metadata for Gnome Software Adds metadata to be used with Gnome Software. Includes name, summary, description and a few screenshots of remote-viewer. Signed-off-by: Lukáš Venhoda <lvenhoda@redhat.com> Acked-by: Daniel P. Berrange <berrange@redhat.com> Acked-by: Fabiano Fidêncio <fidencio@redhat.com>
2016-06-27 18:20:54 +03:00
CLEANFILES += $(mime_DATA) $(desktop_DATA) $(appdata_DATA)
EXTRA_DIST += $(MIMEFILES) $(DESKTOPFILES) $(APPDATAFILES)
Register remote-viewer mime handling Unfortunately, I don't see yet how we could avoid the browser dialog asking which application to open. On Firefox, each user has a mimeTypes.rdf, but we can't really modify it..
2013-01-21 18:09:37 +04:00
nsis: add deps.txt file in installer This helps track package version that were used during the build of Windows installer. It's not ideal, but make up the lack of package management on windows
2012-06-05 23:30:18 +04:00
endif
build-sys: use git.mk to generate gitignore This makefile is just fantastic, it forces you into good practices, support various build targets (my windows builddir ignore the right files etc..) The more I use it, the more I like it.
2012-03-30 04:43:26 +04:00
-include $(top_srcdir)/git.mk
Reference in New Issue Copy Permalink