[illumos-Developer] webrev #687: rpcgen should not generate absolute #includes

[Gordon Ross]

On Thu, May 12, 2011 at 11:49 AM, Gary Mills <mills at cc.umanitoba.ca> wrote:
[...]
>> If we look at, for example, this generated file:
>>   usr/src/uts/common/idmap/idmap_xdr.c
>> The generated "top matter" contains:
>>   #include "/tank/ws/nfslm1/usr/src/uts/common/rpcsvc/idmap_prot.h"
>
> Ah, so it does, although mine has a different absolute path.  I guess
> I've never seen that because I always put my *.x file in the same
> directory as my Makefile.
>
>> If I understand correctly, with the proposed -p option, this would be:
>>   #include "idmap_prot.h"
>>
>> What I'd prefer to have in cases like this is:
>>   #include "rpcsvc/idmap_prot.h"
>
> Yes, /usr/include/rpcsvc contains a collection of *.x and
> corresponding *.h files.  What is the real problem here?  What is
> really missing in rpcgen?  Does it need a search path for *.x files,
> for example?

The problem is that rpcgen gives you no control over how the
include lines are written.  It's all fine when everything is in one
directory, like the RPC examples.  With sofware that divides
things into separate directories like under usr/src/uts, then the
generated include statements don't work quite how you'd like.
(rpcgen does not need a search path, but one would like the
compiler to be able to find your headers when compiling the
generated code, without hacking your CPPFLAGS...)

In the past, I've done a sed pass over the rpcgen generated
files to correct things like this.  And all to often, people just
disregard the admonishment at the top of the generated files
and edit them and check the resutls into SCM.  The proposed
change would avoid many cases where that was needed.

Gordon