nickg
`--work` should take `-L` into account
I ran into an issue using NVC when setting --work=top and setting -L /path/to/dir/containing/top thinking it would take the -L command into account when searching for the work lib, but it does not for some reason.
Per the manual:
-L path
Add path to the list of directories to search for libraries. See the LIBRARIES section below for details.
But also...
In the simple case of
--work=namethe library name is ‘name’ and the physical location is a directory name relative to the current working directory. The physical location can be specified explicitly using--work=name:pathwhere path is the directory name.
So I have a fix, but this seems a bit unnecessary to me.
One additional question. We aren't invoking NVC via a shell so we don't have to worry about the separator : being misinterpreted on Windows. Is that separator still supported on Windows or is there a hard switch between the two depending upon the OS?
EDIT: Answered my own question.
I ran into an issue using NVC when setting --work=top and setting -L /path/to/dir/containing/top thinking it would take the -L command into account when searching for the work lib, but it does not for some reason.
It actually used to work like this a long time ago but I changed it because it seems more important for files to be written in a predictable location (e.g. if you already had a library called top in the search path but forgot about it NVC will silently write its output into an unexpected location) . For scripts and test harnesses the most robust method is to specify the location of all libraries explicitly with --work name:path and --map name:path.
Is that separator still supported on Windows or is there a hard switch between the two depending upon the OS?
Yeah it's not documented but Windows accepts both : and ;. This is mostly to work around the MSYS2 shell silently replacing : with ;. From cmd or PowerShell --map foo:C:\x\y\libdir should work just fine and is unambiguous since we can split on the first :.
