Subject: RE: [sv-cc] Updated proposal for C/C++ file inclusion
From: Amouroux, John (john_amouroux@mentorg.com)
Date: Tue Jan 28 2003 - 09:01:49 PST
Michael,
Here are a few more comments.
-- John
> >
> > 1. default sv_root required?
> > I'm not sure I agree that all the libs with relative paths should be
> > location-independent. I would prefer if the default sv_root was the
> current
> > working directory. But then again, I'm not responsible for
> administering a
> > large group of CAD tool users.
>
> Actually, you bring up a good point here. I think it is shortcoming that
> there is no default defined for sv_root. So what would be
> the actual pathname for a relative pathname in absence of an environment
> variable SV_ROOT and before a -sv_root specification ???
> And yes, it might be a good idea to define the current working directory
> for those cases (although I personally hate such kind of
> definitions, but it makes sense in this cases).
What I would say here is that we only allow at most one -sv_root specifier
which would apply to all the relative paths given for libraries, no matter
where the -sv_root appeared on the command line. And in the absence of an
sv_root, use the cwd.
>
> > 2. Required #!SV_LIBRARIES directive in the bootstrap file
> > Typically these types of "#!" comments are used to direct processing of
> > files to a specific interpreter executable. But in this case there is
> no
> > such executable, so I don't understand the need. Can you explain your
> > reasoning for this?
>
> We are using these kind of identifiers to clearly identify the file type.
> This is very useful to early detect user errors
> (specifying the wrong file) and might also be useful as tag for tools like
> 'file' (similarly to the markers %PDF for PDF files and
> %!PS for PostScript files - Adobe knew why it had inserted them). It is
> much easier to properly abort an errorneous specification
> with a proper error message (wrong file type!) than when relying on some
> parser errors ... Just think about an user mixing the
> object code bootstrap file with the source code bootstrap file. This is a
> likely problem to occur.
I see your point. All I can think of is that maybe we could add a simple
syntax to the bootstrap file, like require them to enter a sv_lib keyword
before each library. Then, a parser could detect that no keywords were
found in a file (if given the wrong file) and issue an appropriate error
message. A keyword could also make this bootstrap file extensible for the
future. We could even accept an sv_root keyword too...
This archive was generated by hypermail 2b28 : Tue Jan 28 2003 - 09:02:45 PST