Hello, On ketvirtadienis 12 Lapkritis 2009 20:36:12 Joey Hess wrote: > How is doing this complicated thing different from simply reordering > cmake before makefile in @BUILDSYSTEMS? It seems like either change > would have equivilant results.
It is similar, but I believe my method is safer. I will explain.
Suppose the package supports both distutils and cmake (I know its rather
unrealistic in real world, but possible). Current @BUILDSYSTEMS order is like:
our @BUILDSYSTEMS = (
"autoconf",
"perl_makemaker",
"makefile",
"python_distutils",
"perl_build",
"cmake",
"ant",
);
So the package would auto-build with python_distutils currently. In order to
prefer cmake to makefile with current code and not to break build system
encapsulation, we have to move cmake before makefile. So after such a move,
the package will start auto-building with cmake rather than distutils.
With my patch applied, this particular package will continue building with
distutils while all other typical cmake packages will auto-select cmake build
system in all steps (rather than just configure). This is because the concept
of "related" (i.e. derived) is introduced to auto-selection process. If you
want even more control, we could invent our own variable (or subroutine)
rather than generic @ISA to describe that the particular build system is
related and more specific than the other one.
Alternatively we could move cmake after makefile. But if we had a package
which supported makefile (plain) and distutils build systems, it would start
building with distutils rather than makefile after this move.
I don't think my patch is 100% safe. However, I believe it reduces the
probability of backwards compatibility breakages to bare minimum. Do you agree
that we need to solve this problem one way or the other? Currently, cmake is
stuck with possibility to customize configure step only unless the build
system is manually forced...
--
Modestas Vainius <[email protected]>
signature.asc
Description: This is a digitally signed message part.
