bug-autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

distributions build with autoconf are not re-locatable


From: C.J. Adams-Collier
Subject: distributions build with autoconf are not re-locatable
Date: Sat, 29 Sep 2007 01:02:13 +0000

Hey all,

Since we allow multiple absolute paths to be specified as arguments to
./configure, there is no easy way to re-locate a distribution, short
of finding a relative path between --prefix and other paths specified
as absolute.

Arguments to configure scripts which accept paths as their value
follow (this list may include glib-specific arguments, since this is
my use case).  I will refer to these as "path args".

--bindir
--sbindir
--libexecdir
--sysconfdir
--sharedstatedir
--localstatedir
--libdir
--includedir
--datarootdir
--datadir
--infodir
--localedir
--mandir
--docdir
--htmldir
--dvidir
--pdfdir
--psdir
--oldincludedir

To allow autoconf to participate in the generation of relocatable
distributions, I propose that except in the case of --prefix, the use
of absolute paths by path args be deprecated.

Current functionality:

Specification of an absolute path is allowed for all path args.

Proposed post-deprecation functionality:

Specification of an absolute path is only allowed for --prefix.   If
an absolute path is specified for a path arg other than --prefix, the
absolute path will be converted to a path relative to the value of
--prefix.

An argument indicating allowance of absolute paths
(--use-absolute-paths) should be accepted.  Use of this argument will
result in pre-deprecation functionality and a warning about relocation
implications.

Phase one of the deprecation process (say D .. D + 1 year):

* "Notification Copy" should be created for use in documentation and
warning messages.  This copy should include the deprecation schedule,
relocation implications, and feedback contact information.
* pre-deprecation functionality should remain in place
* an optional argument (--use-absolute-paths) may be specified to
explicitly use pre-deprecation functionality.  This would be a no-op
during this phase.
* an optional argument (--use-relative-paths) may be specified to use
post-deprecation functionality
* These new optional arguments should appear in --help output and documentation
* "Notification Copy" should be printed if an absolute path is used
other than with --prefix
* documentation should be updated with "Notification Copy"

Phase two of the deprecation process (say D + 1 year .. D + 2 years)
* post-deprecation functionality should become the default
* The optional argument which indicates usage of post-deprecation
functionality (--use-relative-paths) would become a no-op.
* documentation of this argument would be marked for deprecation
* The optional argument which indicates usage of pre-deprecation
functionality (--use-absolute-paths) would be implemented.
* "Notification Copy" should be updated to indicate that phase two is active.

Phase three of the deprecation process (say D + 2 years)
* References to the optional argument which indicates usage of
post-deprecation functionality (--use-relative-paths) should be
removed
* "Notification Copy" should be updated to indicate completion of
deprecation process

-- 
moo.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]