include paths and include directive tidy up

[felix-salfelder]

Currently admsXml adds '.' (current working directory) to the back of the include path list. This seems wrong and unusual. The C preprocessor has a more well behaved include directive, and does not do this.

NB: C has two different includes (quotes vs angle brackets) and the comparison might be inappropriate. It would be better to compare with some other verilog tool.

NB2: The reason the extra '.' has been added is probably related to the generation of header files (in '.'). This only caused problems (due to race conditions) and is no longer needed.

As a start, the implicit '.' should be removed, and instead specified by the user ('-I.') on demand. Then, less importantly, include directives should be resolved relative to the file they occur in, such that files in the same directory are found (unless found in a path specified by -I).

[ngwood]

Hi Felix.

It is actually at the front still.

Current search order for devel as of 351f20e is

1. current working directory;
2. command line include directories;
3. ADMS include directory.

This is what we want, I think.

[ngwood]

Tested by putting BROKEN constants.vams file in current working directory.

bash> admsXml -x dummy.va 
[info...] -x: skipping any implicit xml scripts
[info...] admsXml-2.3.7 (unknown) Jan  2 2022 01:08:04
[fatal..] constants.vams: during lexical analysis syntax error at line 36 -- see 'THIS_IS_A_BAD_LINE'
bash> admsXml -x -I./include dummy.va 
[info...] -x: skipping any implicit xml scripts
[info...] admsXml-2.3.7 (unknown) Jan  2 2022 01:08:04
[fatal..] constants.vams: during lexical analysis syntax error at line 36 -- see 'THIS_IS_A_BAD_LINE'
bash> rm constants.vams 
bash> admsXml -x -I./include dummy.va 
[info...] -x: skipping any implicit xml scripts
[info...] admsXml-2.3.7 (unknown) Jan  2 2022 01:08:04
[info...] elapsed time: 0 (second)
[info...] admst iterations: 0 (0 freed)

[ngwood]

I see no issue with removing the implicit -I. though, especially as this is not a standard thing to do and may catch people out! I also like the idea of adding in the implicit relative search path from the file containing the include.

[felix-salfelder]

On Mon, Jan 03, 2022 at 07:39:15AM -0800, Neal wrote: Current search order for `devel` as of 351f20e is 1. current working directory; 2. command line include directories; 3. ADMS include directory. This is what we want, I think.

It should be changed to

1. command line include directories; 2. ADMS include directory.

because it makes more sense: you can add -I., but you can't un-add it. Or: Find how do other tools implement `include, and decide based on that. Your -I patch + this fix + constants.vams is a good incentive to make a release I reckon.

[ngwood]

Removing it makes sense. I know that doing this alone will cause the Xyce buildxyceplugin script and all of their internal Makefiles to break for multi-file models though. Worst case, they can just add an explicit -I. in the files and still be usable with previous versions of ADMS. (This would also be a good reason for buildxyceplugin to add an interface to -I; it's inconvenient not having one!)

It would be good to also implicitly look relative to the file being processed though, as that is fairly standard practice; e.g.,

`include "relative/include/file.vams"

should look relative to the file being proceed first (instead of the CWD) and then relative to any path declared by by the user with an explicit -I. All that is required to achieve this is to find a way to add the directory of the file being processed to the includePath list, which seems not too tricky. This would also mean that the Xyce build tools would continue to work unchanged.

[ngwood]

Your -I patch + this fix + constants.vams is a good incentive to make a release I reckon.

I would suggest we fix issue #39 too. The earliest version of disciplines.vams available from Accellera cannot be processed with ADMS, in part, because of this. I don't know enough about Bison to fix this myself (yet). There is also another syntax change that would need to be fixed; again, a Bison change.

[ngwood]

I found a fix for issue #39 already. The last related thing I would suggest to get ADMS usable with the most recent Accellera standard library files is to get around their (presumably deliberate) use of an escaped identifier inside the disciplines.vams file. These are identifiers that are allowed to have extra special characters (not just $) in the name; namely any printable ASCII character, such as @, ", {, etc. This is a universal feature of the Verilog-AMS language, but no one actually uses this feature of the language as I don't think anyone supports it. Given that the offending identifier \logic (note the space at the end) is equivalent to the identifier logic (trailing space is irrelevant in free-form language) I suggest we do a nasty hack!

bash> git diff
diff --git a/admsXml/verilogaLex.l b/admsXml/verilogaLex.l
index ea1dfe4..4faabbb 100644
--- a/admsXml/verilogaLex.l
+++ b/admsXml/verilogaLex.l
@@ -274,6 +274,7 @@ INF {TKRETURN(yytext,yyleng); return tk_inf;}
 \|\| {TKRETURN(yytext,yyleng); return tk_or;}
 \^\~ {TKRETURN(yytext,yyleng); return tk_bitwise_equr;}
 
+\\{ident} {TKRETURN(yytext,yyleng); return tk_ident;}
 \${ident} {TKRETURN(yytext,yyleng); return tk_dollar_ident;}
 {char} {TKSTRIPPEDRETURN(yytext,yyleng); return tk_char;}
 {b8_int} {TKRETURN(yytext,yyleng); return tk_integer;}

It's not great but it's much better than not doing anything at all. We'd just need to document the heck out of this!

What do you think?

[tvrusso]

Just weighing in here: I do not really like the suggestion of removing "search current directory" as a default behavior for ADMS, mostly because of the impact it will have on Xyce's use of ADMS.

Verilog-A models are often shipped as bundles of files that include each other in the same directory, and requiring an explicit "search this directory" command line option would be annoying given that it has always been the default behavior for as long as ADMS has existed.

Could we please just leave it as it is?

[felix-salfelder]

On Mon, Jan 03, 2022 at 11:43:50AM -0800, Tom Russo wrote: Verilog-A models are often shipped as bundles of files that include each other in the same directory, and requiring an explicit "search this directory" command line option would be annoying given that it has always been the default behavior for as long as ADMS has existed.

I see your point. Note that "include each other in the same directory" was never the behaviour (unless that directory happens to be '.').

Could we please just leave it as it is?

If someone sends a patch to make "include each other in the same directory" work, I will certainly consider it. Better pass '-I.' where needed.

[tvrusso]

I will note that other Verilog-A compilers (Agilent's, for example) search for include files without a specified path by looking first in the same directory as the file being processed, then in any other search path given to the compiler.

If ADMS were changed to do that, I'd be behind it (though I'm not going to submit a PR to make it happen). But until that happens, please do not remove the default of looking in the current working directory first. Especially since this is long-standing behavior since the dawn of ADMS.

[felix-salfelder]

On Mon, Jan 03, 2022 at 12:21:00PM -0800, Tom Russo wrote: I will note that other Verilog-A compilers (Agilent's, for example) search for include files without a specified path by looking first in the same directory as the file being processed, then in any other search path given to the compiler.

Thanks. That confirms my suspicion.

If ADMS were changed to do that, I'd be behind it (though I'm not going to submit a PR to make it happen). But until that happens, please do not remove the default of looking in the current working directory first. Especially since this is long-standing behavior since the dawn of ADMS.

Agreed, lets do all or nothing.

[ngwood]

This appears to be all that is needed for this.

diff --git a/admsXml/admsXml.c b/admsXml/admsXml.c
index 5d314b4..9dba440 100644
--- a/admsXml/admsXml.c
+++ b/admsXml/admsXml.c
@@ -615,7 +615,7 @@ static void parseva (const int argc,const char** argv,char* myverilogamsfile)
     pproot()->error=0;
     adms_slist_push(&pproot()->skipp_text,(p_adms)(long)(0));
     pproot()->includePath=getlist_from_argv(argc,argv,"-I","directory");
-    adms_slist_push(&pproot()->includePath,(p_adms)".");
+    adms_slist_push(&pproot()->includePath,(p_adms)dirname(myverilogamsfile));
 #ifdef ADMS_INCLUDEDIR
     adms_slist_concat(&pproot()->includePath,adms_slist_new((p_adms)ADMS_INCLUDEDIR));
 #endif

This would make ADMS behave similarly to other Verilog-A compilers. I am fairly sure that this wouldn't interfere with how Xyce uses ADMS. The CWD could always be manually added with the -I. command line option.

[felix-salfelder]

On Mon, Jan 17, 2022 at 04:36:04AM -0800, Neal wrote: - adms_slist_push(&pproot()->includePath,(p_adms)"."); + adms_slist_push(&pproot()->includePath,(p_adms)dirname(myverilogamsfile)); This would make ADMS behave similarly to other Verilog-A compilers. I am fairly sure that this wouldn't interfere with how Xyce uses ADMS. The CWD could always be manually added with the `-I.` command line option.

Thanks for looking into this one. I have doubts about the correctness of the approach, and I am unsure what "correct" even means. How about A.va # `include "sub/B.va" sub/B.va # `include "C.va" sub/C.va # the desired file C.va # a stray (but wrong) file. Will it not include the wrong one? (What will others do here?) What happens if -I. is passed in the above example? will C.va or sub/C.va win? Is there anything in the standard on this at all? (Same question with -Isub, and no "sub/" in A.va.) I like the idea of a tradeoff between unconditional -I. and a correct implementation, and I think your patch has a chance. What if users start depending on odd behaviour (again)?

[ngwood]

Ahh yes. This will not work with nested include files. It will only add the directory of the base Verilog-A file to the include path. I will give this some more thought.