These changes are badly needed. The current build system is a long
running amalgam of poor implementation decisions and a failed experiment
to dynamically consume components as they are added. Having separate
packages for noxcore (which may or may not include coreapps), netapps,
and webapps is probably the right way to go about this. I know KK and
Murphy have been thinking about distribution a bit, and should probably
chime in. I definitely think we should just do a wholesale upgrade.
The most current work on Nox is going on in the destiny branch.
KK/Murphy, I know there has been some work in overhauling
building/config, where does that stand?
.. and ForkdNox is a great name. ;)
.martin
Hi,
I am currently trying to create a Debian package for NOX. I
encountered many issues with NOX's autotools-based packaging that make
it very difficult to package, listed below.
I propose two strategies to handle those issues and obtain a NOX
version that can be properly made into a Debian package:
1) I have patches that solve almost all those issues. It's a lot of
work, it's not finished, and I'm not yet satisfied with the result.
Are you OK to do such an overhaul of NOX's build system? I.e. would
you be willing to review and integrate such patches?
2) It's such a frustrating work that I'd just prefer to fork NOX and
do a clean, minimal version including only a working nox-core
implementation and a new set of configure.ac / Makefile.am files
redone from scratch. The rest of the code could be packaged
separately, from another source.
(I think the name "Forkt NOX" would be good for this ;))
Which strategy do you think is better?
My issues:
- the use of a heavy-handed boot.sh script to configure the parts of
the system to build, instead of using Autoconf's standard
AC_ARG_ENABLE macros to add --enable-X / --disable-X options to the
configure script, and then defining and using variables that can be
tested in Makefiles to enable options;
- the use of a custom M4 macro for testing for Python, instead of
using Automake's AM_PATH_PYTHON which at least correctly selects the
correct Python version when multiple versions of Python are installed
in the system and defines correctly the installation directory for
Python files ($pythondir):
- pythondir is calculated by AM_PATH_PYTHON using this code:
from distutils import sysconfig
print sysconfig.get_python_lib(0,0,prefix='$prefix')
i.e., this code correctly takes into account the prefix
- PYTHON_SITE_PKG is calcualted by AC_PYTHON_DEVEL (used by NOX)
using this code;
import distutils.sysconfig
print distutils.sysconfig.get_python_lib(0,0)
i.e., it doesn't take into account the configured prefix so
PYTHON_SITE_PKG cannot be used as-is as an installation dir
- at install time, all Python sources are installed in prefix/...,
then compiled using the configured version of Python, and then deleted
for no good reason; this makes it impossible to install NOX to support
multiple versions of Python in the same system. The Debian way, e.g.
using python-support, is to: first install the Python sources in a
Python version-independent directory, normally
$prefix/share/pyshared/, and then let python-support compile the
sources for every version of Python installed in the system, e.g. into
$prefix/share/python-2.6/site-packages/,
$prefix/share/python-2.4/site-packages/, etc.
- all the Python sources are installed into $prefix/bin, even Python
files that are not meant to be executables; this is just wrong: Python
sources should normally be installed into $prefix/share/python-*/ (or
preferably into $prefix/share/pyshared/), Python extension modules
(.so libs, etc.) should be installed into the dir for each supported
version of Python ($exec_prefix/lib/python-*/site-packages);
- just anything is installed along with the Python source files
(listed in the NOX_RUNTIMEFILES variables): I've found Swig *.i files,
C++ *.cc source code files, *.sh test scripts, config files (meta.xml)
etc. Those should really be installed separately, into different
directories.
- specifically for the meta.xml, it would be better to install them
into a specific directory containing only those files, e.g.
$pkgdatadir/ (i.e. $prefix/share/nox/...);
- test files should not be installed at all (cf. the .../t/
directories for instance);
- the SSL certificates are generated at build time, included into the
dist archive, and then copied at install time. Without modification,
it would mean that all users installing from a dist archive or from a
Debian package made from this unmodified build system would use the
same SSL certificate, which of course must be absolutely avoided. The
SSL certificates should instead be generated much later, at package
installation time. They should at least not be generated at build
time, and not be included into the dist archive.
- there are several hard-coded paths in the source code, e.g. in
switch_command.py there is this line:
sys.path.append('/opt/nox/bin')
- a lot of files are just not listed in the Makefiles, and as a
consequence are not included in the dist archive (generated with "make
dist"), and sometimes not even built or installed. For instance, the
src/scripts is not even listed in the SUBDIRS of src/Makefile.am, so
its files cannot be included into the dist archive. Or the *.txt files
in src/tests/.
- some temporary files are not cleaned properly. For instance,
src/lib/dhparams.c should be in the CLEANFILES and should not even be
present in the Git repository;
- some Makefiles handle files in subdirs, e.g. src/include/Makefile.am
takes care of all the files in subdirectories. That one is not too
bad, but part of the files in src/nox/ are handled by src/Makefile.am,
and the rest is handled by src/nox/Makefile.am, which is confusing.
Why not just have one Makefile.am per directory, as usual, and let
each Makefile.am handle all the files in its directory, and only those
files?
FYI, I'm working using the openflow-1.0 branch.
Best regards,
--
Romain Lenglet
_______________________________________________
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
_______________________________________________
nox-dev mailing list
nox-dev@noxrepo.org
http://noxrepo.org/mailman/listinfo/nox-dev_noxrepo.org
