Re: [Groff] new automake system

[Ingo Schwarze]

Hi Werner,

Werner LEMBERG wrote on Thu, Sep 25, 2014 at 11:35:26AM +0200:
> Ingo Schwarze wrote:

>>  - it prefers /usr/local/bin/gsed over /usr/bin/sed
>>  - it prefers /usr/local/bin/bison over /usr/bin/yacc
>> 
>> Prefering the GNU versions over the native POSIX versions
>> is bad because it causes needless build dependencies.

> Mhmm.  I don't find Ingo's arguments really convincing, but he has a
> point that this preference should be documented somewhere, giving the
> user (or packager) a possibility to override it.

I'm not quite sure where to put that documentation, but maybe it can
somehow be done after switching to the new build system.

> groff is a GNU package, and *of course* it prefers GNU sed
> and GNU bison over non-GNU tools!  In particular, you can be sure
> that you get predictable, repeatable builds.

>> For end-users, it compromises predictable, repeatable builds.

> I think exactly the opposite. 

I think i finally understand where this difference in perspective
comes from:

In the GNU/Linux world, many systems (apart from the kernel and
maybe the coreutils and maybe a very small number of other
components) consist of a variable set of packages, and each
distribution, and to a certain extent each user, is free to
assemble their system from whatever components they want.
Alternative implementations are often considered just that,
alternatives, none being intrinsically prefered over another.
So telling any package which dependencies to prefer may seem
like an unwelcome intrusion.  Predictable, here, means "use
whatever the package in question expects".

In the BSD world, by contrast, the whole system including the
kernel, a full POSIX compatible userland, and many other base
system tools is regarded as one indivisable entity, intended
to work smoothly together as one whole.  So any package trying
to replace base system tools, in particular those standardized
by POSIX like sed(1) and yacc(1), is regarded as pushing
unwelcome idiosyncracies.  Predictable, here, means "use
standardized tools, not arbitrary extensions."

Probably not much can be done about this cultural gap.

Fortunately, we do have solutions to do what we want.  For example,
our ports build system uses these definitions by default:

  ac_cv_path_CHMOD=${ac_cv_path_CHMOD=/bin/chmod}
  ac_cv_path_CP=${ac_cv_path_CP=/bin/cp}
  ac_cv_path_DIFF=${ac_cv_path_DIFF=/usr/bin/diff}
  ac_cv_path_EGREP=${ac_cv_path_EGREP=/usr/bin/egrep}
  ac_cv_path_FGREP=${ac_cv_path_FGREP=/usr/bin/fgrep}
  ac_cv_path_fp_prog_find=${ac_cv_path_fp_prog_find=/usr/bin/find}
  ac_cv_path_fp_prog_sort=${ac_cv_path_fp_prog_sort=/usr/bin/sort}
  ac_cv_path_GREP=${ac_cv_path_GREP=/usr/bin/grep}
  ac_cv_path_mkdir=${am_cv_prog_mkdir=/bin/mkdir}
  ac_cv_path_RM=${ac_cv_path_RM=/bin/rm}
  ac_cv_path_SED=${ac_cv_path_SED=/usr/bin/sed}
  ac_cv_prog_AWK=${ac_cv_prog_AWK=/usr/bin/awk}
  ac_cv_prog_egrep=${ac_cv_prog_egrep='grep -E'}
  ac_cv_prog_LEX=${ac_cv_prog_LEX=flex}
  ac_cv_prog_SED=${ac_cv_prog_SED=/usr/bin/sed}
  ac_cv_prog_SORT=${ac_cv_prog_SORT=sort}
  am_cv_prog_tar_ustar=${am_cv_prog_tar_ustar=/usr/bin/tar}
  lt_cv_path_SED=${lt_cv_path_SED=/usr/bin/sed}
  AMTAR=${AMTAR=/usr/bin/tar}
  SED=${SED=/usr/bin/sed}
  [...]

I just hoped the need for such workarounds could be lessened,
but apparently, it cannot.

Yours,
  Ingo