Matt, I've uploaded a new version of this Mantis proposal last night Here is how the modified text will read The filename can be enclosed in either quotes or angle brackets, which affects how a tool searches for the file. - When the filename is enclosed in double quotes ("filename"), for a relative path the compiler's current working directory, and optionally a user specified location is searched. - When the filename is enclosed in angle brackets (<filename>), then only an implementation-dependent location containing files defined by the language standard is searched. Relative path names are interpreted relative to that location. When the filename is an absolute path, only that filename is included and only the double quote form of the `include can be used. A file included in the source using the `include compiler directive may contain other `include compiler directives. The number of nesting levels for include files shall be finite. Implementations may limit the maximum number of levels to which include files can be nested, but the limit shall be at least 15. Examples of `include compiler directives are as follows: `include "parts/count.v" `include "fileB" // including fileB `include <List.vh> ________________________________ From: owner-sv-bc@server.eda.org [mailto:owner-sv-bc@server.eda.org] On Behalf Of Bresticker, Shalom Sent: Tuesday, February 12, 2008 11:35 PM To: Gran, Alex Cc: sv-bc Subject: RE: [sv-bc] `include Alex, On items 3 and 8: `include using double-quote form checks working directory, and any other paths specified by user, typically via +incdir switch on command line. The <> form ignores the user-specified paths (+incdir). "files defined by the language standard" refers, to the best of my understanding, to the List.vh package file defined in Annex H. H.3 says, "To declare a specific list, users must first include the generic List class declaration from the standard include area and then declare the specialized list type: 'include <List.vh> ... List#(T) dl; // dl is a List of 'T' elements" I think the LRM is ambiguous whether the file name must be List.vh, but let's ignore that. So I would like "files defined by the language standard" to be followed by "(See Annex H)". The LRM implies that this special directory where List.vh is found is not automatically searched by the "" form. Regarding item 5, I guess you can consider a filename to be a special case of a relative path. Regards, Shalom ________________________________ From: Gran, Alex [mailto:alex_gran@mentor.com] Sent: Tuesday, February 12, 2008 6:53 PM To: Bresticker, Shalom Cc: sv-bc Subject: RE: [sv-bc] `include Shalom, I am uploading a 2nd version of the proposal after taking your feedback into account, ________________________________ From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com] Sent: Wednesday, February 06, 2008 2:45 AM To: Gran, Alex Cc: sv-bc Subject: RE: [sv-bc] `include Alex, Your proposal reads as follows: The filename can be enclosed in either quotes or angle brackets, which affects how a tool searches for the file. - When the filename is enclosed in double quotes ("filename"), for relative a path the compiler's current working directory, and optionally an implementation-dependent search-path specified by the user is searched. - When the filename is enclosed in angle brackets (<filename>), then only an implementation-dependent location is searched. Relative path names given inside the angle brackets are interpreted relative to the implementation-dependent location in all cases. 1. Regarding "vendor-defined" vs. "implementation-dependent", although "vendor-defined" may not appear elsewhere, "vendor" does and in various combinations, such as "vendor-supplied". I'm not sure it matters. 2. There is a grammar error, "for relative a path". Did you mean, "for a relative path"? [AG] Yes, thanks for catching that, it was a typo. I was going back and forth between singular 'path' and plural 'paths' and put the 'a' in the wrong place. 3. For the double-quote form, I don't think "implementation-dependent" and "specified by the user" go together. [AG] I've made both the double quote and angle bracket form use the phrase "optionally an implementation-dependent location containing files defined by the language standard 4. "search path" + "is searched" = redundancy. [AG] yeah, noticed that, but was trying to keep the text for both forms structured the same. The redundancy is no longer there in my new proposal 5. For the double-quote form, it omits the case where the filename is just a name and not a path. [AG] Isn't a file name just a path with an implicit ./ ? 6. This omits the information that the "files defined by the language standard" are to be in the implementation-dependent location. [AG] I wasn't really sure what value that phrase was adding, but it is no longer removed 7. The last sentence could be simplified to "Relative path names are interpreted relative to that location." 8. The LRM should clarify explicitly whether the implementation-dependent location is searched for the double-quote form. The LRM implies it is not, but it should be explicit. [AG] So your believe the LRM should say that double quote form; search *only* current working directory and angle bracket form; search *only* implementation-dependent location? Is that what implementations are doing currently? Regards, Shalom --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -- This message has been scanned for viruses and dangerous content by MailScanner <http://www.mailscanner.info/> , and is believed to be clean. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Mon Mar 3 11:56:09 2008
This archive was generated by hypermail 2.1.8 : Mon Mar 03 2008 - 11:57:03 PST