- Have the buid system generate a file which exports the install paths
for the hotplug scripts and stubdom / stubdom-dm
- Move file generation code from tools/python/Makefile into a gmake
macro
in Config.mk to avoid maintenance of three duplicates each with its
own
tweaks and bugs
- Export gmake variables into ioemu as shell variables
for upcoming ioemu patches
- Do above as a gmake macro to avoid maintenance of several duplicates
- Adjust hotplug scripts to find the right xen binaries from the
install directory
- Adjust stubdom-dm to use the install directories
Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
* Install create.dtd in SHAREDIR
* Use SHAREDIR/create.dtd
* import os.path.join into xenapi_create.py,
it already seems to be used many times
Resolves the following error when using XenAPI:
$ xm create hvm.conf
Couldn't open resource '/usr/share/xen/create.dtd' at
/usr/share/xen/create.dtd:1:0
Signed-off-by: Simon Horman <horms@verge.net.au>
Remove *all* hardcoded "/etc/xen" strings in python code.
Additionally, it removes pygrub_path from osdep.py. Its use has been
replaced with auxbin.pathTo("pygrub").
Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
We change all invocations of setup.py as follows:
* use $(PYTHON) instead of `python' so that the user can specify
an alternative python version if they need to. If not set it
defaults to `python' in Config.mk.
* pass --prefix=$(PREFIX) via a new make variable
$(PYTHON_PREFIX_ARG). This allows a user to suppress the
--prefix=... argument entirely by setting PYTHON_PREFIX_ARG=''.
This will work around the bug described here
https://bugs.launchpad.net/ubuntu/+bug/362570
where passing --prefix=/usr/local (which ought to have no effect as
/usr/local is the default prefix) changes which subdirectory
distutils chooses, and results in the files being installed in
site-packages which is not on the default search path.
Users not affected by this python packaging bug should not set
PYTHON_PREFIX_ARG and their builds will not be affected. (Provided
PREFIX did not contain spaces. People who put spaces in PREFIX are
being quite optimistic.)
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Previously, by default we would install our python modules into
/usr/lib/python/xen, for example /usr/lib/python/xen/__init__.py.
Upstream python's standard install location (a) includes the Python
version number and (b) puts things in site-packages by default.
Our best conjecture for the reason for this was an attempt to make the
installs portable between different python versions. However, that
doesn't work because compiled python modules (.pyc), and C python
extensions corresponding to one version of python, are not compatible
across different versions of python.
This is why upstream include the version number.
site-packages is the standard location for locally-installed packages
and is automatically included on the python search path.
In this change, we abandon our own unusual python path setup:
* Invoke setup.py in an entirely standard manner. We pass
PREFIX and DESTDIR using the appropriate options provided by
setup.py for those purposes (adding them to setup.py calls
which were previously lacking them).
* Since the installation locations are now on the standard
python path, we no longer need to add anything to the path
in any of our python utilities. Therefore remove all that
code from every python script. (Many of these scripts
unconditionally added /usr/lib/python and /usr/lib64/python which
is wrong even in the old world.)
* There is no longer any special `Xen python path'. xen-python-path
is no longer needed. It is no longer called by anything in our
tree. However since out-of-tree callers may still invoke it, we
retain it. It now prints a fixed string referring to a directory
which does not to exist; callers (who use it to augment their
python path) will thus add a nonexistent directory to their python
path which is harmless.
* Remove various workarounds including use of setup.py --home
(which is intended for something completely different).
* Remove tests for the XEN_PYTHON_NATIVE_INSTALL build-time
environment variable. The new behaviour is the behaviour which we
should have had if this variable had been set. That is, it is now
as if this variable was always set but also bugs in the resulting
install have been fixed.
This should be a proper fix for the bug addressed by c/s 19515.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
attached patch lets python install the modules into
DESTDIR/PREFIX as before, but lets python search
the modules in PREFIX rather DESTDIR/PREFIX.
This prevents failures about not finding python modules
after files have been installed into PREFIX.
Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
If you use -MMD -MF then the correct .o filename is written to the
.*.d file as the compiler driver arranges everything. This was done
in 19010:275abe1c5d24 for the hypervisor.
In this patch we do the same elsewhere in the xen-unstable tree,
particularly tools/. Specifically:
* Change tools/Rules.mk to add -MMD -MF ... to CFLAGS and set DEPS.
* Remove -Wp,-MD... from every other Makefile
* Remove setting of DEPS from every other Makefile
* Ensure that every Makefile says -include $(DEPS)
* Ensure that every Makefile's clean target removes $(DEPS)
Some Makefiles were already halfway there, but often for a different
variable name eg PROG_DEP. The variable name is now standardised in
Rules.mk as DEPS.
I have done a test build with this change, on Debian etch.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
- The patch does away with the autogenerated xsm.py file and
introduces a config parameter in xend-config.sxp to determine the
security module. The parameter is (xsm_module_name {acm, dummy,
flask}). The default setting/option is dummy. .hgignore is also
updated to stop ignoring xsm.py on commits.
- The patch has created an xsconstant for XS_POLICY_FLASK and updated
the toolchain to check the instance of XS_POLICY_USE. XS_POLICY_USE
evalauates to XS_POLICY_FLASK or XS_POLICY_ACM or XS_POLICY_DUMMY
depending on configuration.
- Flask relies on the current value of ssidref returned by dominfo to
ensure that the label to sid mapping is consistent. ssidref had
been pop'ed from the dominfo object. The patch addresses this
issue.
- Flask python module style cleanups.
Signed-off-by: George Coker <gscoker@alpha.ncsc.mil>
Many of the tools use C99 features such as bool, or expect certain functions.
Fix the CFLAGS to enable these on Solaris.
Also make sure the correct $CC is passed to Python.
Signed-off-by: John Levon <john.levon@sun.com>
* Move .PHONY directives next to targets,
this makes them a lot harder to miss
* Add missing .PHONY directives
* Remove nonexistent .PHONY directives
* Hopefully I didn'T miss anything...
Signed-Off-By: Horms <horms@verge.net.au>
exciting, but it's there to encourage the creation of more interesting ones. A
test target has been added to the main Makefile, and the one in tools/python.
Signed-off-by: Ewan Mellor <ewan@xensource.com>
Python packages can be installed to the Python installation's 'native'
location, instead of generic /usr/lib/python, by specifying
XEN_PYTHON_NATIVE_INSTALL in the environment or on the make command line.
Signed-off-by: Keir Fraser <keir@xensource.com>
[PATCH] add-build.patch
Add build targets to all makefiles. Debian does builds as non-root, so
it's better to do as much as possible before requiring root privs.
Signed-off-by: Adam Heath <doogie@brainfood.com>
Description: use DESTDIR correctly
Standard makefiles always attempt to install to the root(/). Setting
DESTDIR is the normal way to install to an alternative location.
Setting prefix has the possibility of breaking programs, as the prefix
may have been embedded inside a compiled binary.
From: Adam Heath <doogie@brainfood.com>
Signed-off-by: ian.pratt@cl.cam.ac.uk
Keir Fraser
kfraser@localhost.localdomain
James Bulpin
Tom Wilkie
Christian Limpach
kaf24@localhost.localdomain
Ewan Mellor
kaf24@firebug.cl.cam.ac.uk
emellor@ewan
ewan@linford.intra
kaf24@viper.(none)
doogie@brainfood.com[kaf24]
kaf24@scramble.cl.cam.ac.uk
iap10@labyrinth.cl.cam.ac.uk
mjw@wray-m-3.hpl.hp.com