[Thales] Re: GNU thales build system

[Lucas Nussbaum]

[[ Thales mailing list Cced, so it gets archived ]]

On 04/03/06 at 12:39 -0500, Claudio Fontana wrote:
> Hello,
> 
> I am writing you about the GNU thales project,
> as part of my effort to help GNU projects provide a better, more
> consistent build system.
> 
> Currently, your project provides a build system that is not 
> fully compatible with GNU policies
> (as described in the GNU coding standards, and in the autoconf, make
> and automake manuals).
> 
> Often it is very easy to adapt a custom build system to satisfy GNU
> policies requirements.

Hi,

I lost interest a long time ago in GNU Thales. While it still work for
some (most ?) users, there hasn't been any work done on it for a long
time, and nobody stepped up to replace me as maintainer.

I still hope somebody will step up and use your mail's infos to improve
the build system, but I won't do it myself.

Thank you,

Lucas

(Following: rest of Claudio's mail)

> In this case, the configure script should not require input from the
> terminal. All user options relative to configuration must be read from
> the command line parameters. See AC_ARG_ENABLE, AC_ARG_WITH in the
> autoconf manual for an easy way to deal with options.
> 
> I have also noticed that you already support DESTDIR in your generated
> Makefiles via automake.
> However, in some of your data installation targets and hooks
> DESTDIR is not considered, and this can result in a broken build
> if the user tries to install using DESTDIR.
> The fix is as easy as to prepend $(DESTDIR) to your destination directories,
> as in:
> 
> install-data-local:
>         @if test -f $(DESTDIR)$(pkgdatadir)/thales.conf ; then \
>            echo "$@ will not overwrite existing 
> $(DESTDIR)$(pkgdatadir)/thales.conf" ; \
>         else \
>            echo "$(INSTALL_DATA) thales.conf.default 
> $(DESTDIR)$(pkgdatadir)/thales.conf"; \
>            $(INSTALL_DATA) thales.conf.default 
> $(DESTDIR)$(pkgdatadir)/thales.conf; \
>         fi
> 
> Note that hard-coded paths, and other references in the installed binaries
> and data which depend on installed files locations must _NOT_ contain
> DESTDIR. DESTDIR installation needs
> to produce a build that will work when moved to the final installation prefix,
> which is specified by --prefix.
> 
> You do not need to override bindir, sbindir and datadir.
> You can define your custom variables as you need.
> Also, instead of datadir, you can use pkgdatadir, which is already datadir
> with your package name appended.
> 
> At the end of the day, users and programs should be able to build and
> install the package running:
> 
> $ ./configure [--prefix=]
> $ make
> $ make install [DESTDIR=]
> 
> DESTDIR support is marked as optional in the GNU coding standards,
> but in my opinion, DESTDIR can be very helpful for the user, the
> distribution-specific packagers and third-party programs, because it
> offers a consistent and portable way to perform staged installations.
> 
> Some links for additional information:
> 
> GNU Coding Standards [the only one which is really a necessary read]
> http://www.gnu.org/prep/standards/
> 
> GNU autoconf manual [could help]
> http://www.gnu.org/software/autoconf/manual/autoconf-2.57/html_mono/autoconf.html
> 
> GNU make manual [could help]
> http://www.gnu.org/software/make/
> 
> GNU automake manual [could help]
> http://www.gnu.org/software/automake/manual/
> 
> In each case, please contact me at this address <address@hidden>
> to provide your feedback about this issue.
> I am ready to offer you information, help and support.
> 
> Thank you for your help in making GNU projects build systems better.
> 
> Claudio Fontana
>