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

[Gordon Ross]

On Thu, May 12, 2011 at 7:37 AM, Stepan Zastupov
<stepan.zastupov at gmail.com> wrote:
> Here is the updated patch:
> http://cr.illumos.org/view/0ig2ulcs/illumos-687-webrev/
>
> This version makes cstyle happy.
>
> On Wed, May 11, 2011 at 7:10 PM, Stepan Zastupov
> <stepan.zastupov at gmail.com> wrote:
>> This patch introduce option -p to prevent rpcgen from generating
>> includes with absolute paths.
>> A few notes:
>> 1) I use basename(3) function, which conforms to POSIX.1-2001. Is it fine?
>> 2) I haven't documented the option since I'm not sure is '-p' a good name.
>>
>> http://cr.illumos.org/view/mchniy2i/illumos-687-webrev/

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"

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"

So, how about a more flexible option?  Perhaps:

-X include_prefix
    Set the prefix path used for include statements
    in generated code.  For example:
        rpcgen -X "rpcsvc/" ... idmap_prot.x
    would generate includes like this:
        #include "rpcsvc/idmap_prot.h"
    and to get no prefix at all, use:
        rpcgen -X "" ... idmap_prot.x
    which would generate includes like this:
        #include "idmap_prot.h"
   The default (with no -X option) would be
   the current behavior, which is to use the
   full path as specified to find the *.x file.

Then, re. implementation - Why add the new args to
all those funtions instead of adding a global option?
That would avoid a bunch of changes.

Factoring out the add_include function looks good.

Thanks,
Gordon