fixincludes & sed question

[Steve Ellcey <sje at cup dot hp dot com>]

I have a question about the use of sed by fixincl and mkheaders
and a change that was made between 4.3.* and 4.4.0.

It involves this patch:

2008-09-06  Bruce Korb  <bkorb@gnu.org>

        * fixincl.tpl (sed): make the program executable configurable.
        Some platforms have some rather oddball defaults.
        * config.h.in (SED_PROGRAM): define the default sed.
        * fixincl.x: regenerated
        * tests/base/internal/wchar_core.h: fix bad sample text
        * tests/base/math.h: fix bad sample text
        * configure.ac: search for working sed
        * inclhack.def (glibc_mutex_init): fix non-portable construct
        and re-order a few misordered entries.

Prior to this patch, when a user ran mkheaders to fix up the GCC
headers, mkheaders would call fixincl and fixincl would call sed.
The sed that was called was found using the path you had when
running mkheaders.

After this patch, the sed used when building GCC is saved in a config
file and that path to sed is used when you run mkheaders.  This is
a problem if mkheaders is run after the GCC build and the sed used
is no longer available.

I ran into this problem because when I build GCC I use a GNU sed
that I have in my build environment along with GCC, bison, the
auto* tools, etc.  But then I package GCC up for users into a 
bundle which when installed will automatically run mkheaders on
their system in order to make sure the GCC headers are in sync
with their system headers which may or may not be identical to the
ones on the system where I built GCC.  They don't have my build
environment available and so sed is not found and the mkheaders
command fails.

I am wondering if it is reasonable to require having the 'build sed'
available anytime we want to run mkheaders?

I can work around this by removing the sed from my build environment
(causing it to use /usr/bin/sed) or should we could change fixincl to
default to using path to find sed if the configured one can't be found?

Steve Ellcey
sje@cup.hp.com