CMake a 0.2 release goal?
Nicolas Alvarez
I'm mainly wondering whether I should put any more time into the autotools
build system. For example, issue 25 (compiling language files) is something
that I think should be fixed for 0.2. But adding support for it in automake
(without using gettextize, which seems bloated) is non-trivial work. It
would be worth doing if 0.2 will be still compiled with automake, but not if
we're going to switch to CMake.
On the other hand, there is also some way to go before CMake is ready for a
release:
- Issue 69 makes the client unusable on Linux (platform not detected).
- There is no "make install".
- We have no way to create a source tarball (automake creates a "make dist"
target by default, CMake doesn't).
- Not tested enough on Windows and Mac.
Opinions?
(Please reply to this message directly, don't answer through IRC; the
mailing list exists for a reason!)
--
Nicolas
(I read mailing lists through Gmane. Please don't Cc me on replies; it makes
me get one message on my newsreader and another on email.)
Der Meister
> Should we replace autotools with CMake as a release goal for 0.2?
> - There is no "make install".
Is this really a problem? I usually don't use "make install" at all.
Either I let the package manager install things or if I really compile
from source than because I want to do somthing with the source. Running
"make install" isn't really usefull for debugging and things like this.
> - We have no way to create a source tarball (automake creates a "make dist"
> target by default, CMake doesn't).
Do we really need a build-script for this?
> - Not tested enough on Windows and Mac.
Windows is no problem, there are still the visual studio project files.
I have no problem with calling cmake support for 0.2 on windows as
experimental.
Nicolas Alvarez
> Nicolas Alvarez wrote:
>> - There is no "make install".
> Is this really a problem? I usually don't use "make install" at all.
> Either I let the package manager install things or if I really compile
> from source than because I want to do somthing with the source. Running
> "make install" isn't really usefull for debugging and things like this.
Remember the core client is already hardcoding the data directory path to
$PREFIX/var/synecdoche. In the future there may be more reasons why it needs
to be installed. For example, I think the translation files after compiling
will not be in the correct directory structure to be loaded by the manager,
"make install" will copy them into the right places and only then the
manager will be able to load them.
End-users building from source definitely need "make install".
Also, we need "make install" to create a Linux distro package. The way
binary package building works is it runs "make; make install DESTDIR=foo;"
and then tarballs the contents of the 'foo' directory.
>> - We have no way to create a source tarball (automake creates a "make
>> dist" target by default, CMake doesn't).
> Do we really need a build-script for this?
There should be as few manual steps as possible in turning a SVN checkout
into a ready-to-release package. Less manual steps = less possible errors.
Nicolas Alvarez
> Nicolas Alvarez wrote:
>> Should we replace autotools with CMake as a release goal for 0.2?
> Yes, if we can fix issue 69.
Nicolas Alvarez
Nicolas Alvarez wrote:
> For example, issue 25 (compiling language files) is
> something that I think should be fixed for 0.2. But adding support for it
> in automake (without using gettextize, which seems bloated) is non-trivial
> work. It would be worth doing if 0.2 will be still compiled with automake,
> but not if we're going to switch to CMake.
issue 25 anyway, in r1366 and later tweaks.
> On the other hand, there is also some way to go before CMake is ready for
> a release:
> - Issue 69 makes the client unusable on Linux (platform not detected).
> - There is no "make install".
> - We have no way to create a source tarball (automake creates a "make
> dist" target by default, CMake doesn't).
sounded.
Also, the contents of our repository trunk are clean enough that we don't
really need to exclude anything from the tarball, so creating a tarball from
the contents of a working copy minus built files (or anything that isn't
already in the repository) and .svn directories is enough.
Of course, that's for CMake builds; for autoconf we need to add other
things, like the generated configure script.
> - Not tested enough on Windows and Mac.
Michael Tughan tested Mac, and at least it compiles, but the manager doesn't
run. It may be a problem with his own environment though.
Along with "make install" support, I should look at getting cmake to create
a Mac application bundle, not just Unix-like binaries. Similar for Windows;
even if it doesn't build an installer, it should at least create a "Windows-
friendly" directory structure (not bin/synecd and share/locale/LC_MESSAGES
for languages).
However, it would be ideal if CMake could build ready-to-release packages
for all platforms. Run "make package" on the three platforms and we're done.
--
Nicolas