Hi,
On Mon, Jun 29, 2009 at 01:28:08AM +0200, olafbuddenha...@gmx.net wrote:
> On Tue, Jun 23, 2009 at 10:39:50AM +0200, Thomas Schwinge wrote:
> > [...] or test and confirm that the attached patch doesn't break
> > anything, which I think that it can't, but who knows...
>
> Guess what? It does break things...
>
> The gnmach build for example does this:
>
> mig -n -cc cat - /dev/null \
> -user vm/memory_object_user.user.c -header
> vm/memory_object_user.user.h \
> -list vm/memory_object_user.user.msgids
> \
> < vm/lib_dep_tr_for_defs_a-memory_object_user.user.defs.o
>
> I have no idea what this means, but it works without your patch and
> breaks with it.
Now I understand what happens here.
Various Hurd-related make files use this abominable hack
MIGCOM = mig -cc cat - /dev/null
to invoke migcom only, without any preprocessing (as this is already
done in another step), and reading from stdin -- just like the "real"
migcom; except that we have to go through the mig wrapper, because
migcom is not in the path.
What this hack does, is setting the preprocessor to "cat", and passing
"-" as a preprocessor flag. "/dev/null" is the real argument, so it is
also supplied to our "preprocessor". The result is that cat simply
passes on stdin, and the mig wrapper feeds that to migcom directly.
Your patch breaks this hack, because "-" is no longer treated as a
preprocessor flag.
OTOH, all this means that it's already possible to have mig read from
stdin, without any patches: all we need to do is supply a (real)
preprocessor that reads from stdin. I ended up with this rule for
building the client-side KGI stubs:
%User.h %User.c:
mig -cc '$(CPP) -x c $(CPPFLAGS) -' -imacros kgi/hurd/$*mutations.h
-header kgiUser.h -user kgiUser.c -server /dev/null /dev/null <<<"#include
<kgi/hurd/$*.defs>"
BTW, I have no clue why the standard hack I mentioned above relies on
the obscure handling of "-" as a preprocessor flag: simply doing
MIGCOM = mig -cc 'cat -' /dev/null
is much clearer and more robust...
-antrik-
