Menu
▾
▴
iverilog-devel
|
From: Cary R. <cy...@ya...> - 2009-01-30 20:04:49
|
We have a report in the tracker (pr2533613) requesting a change
to the include search path. I believe we are currently doing
this correctly. What we do almost exactly matches what gcc does.
The request is to make the directory the compiler is running in
be the first directory searched not the directory the file is
located in. The consequence of this is that it is easy and
probably too easy to override any include file.
We do add the compile directory as the second search path
entry. This is the sole difference from gcc and is basically an
implicit -I. at the head of the search path. I believe the
users problem can be worked around with better use of the -I
flag, so the real question is should we keep the implicit -I.
or should we make this match gcc exactly?
Here's what cpp-3 says:
GCC looks for headers requested with #include "file" first
in the directory containing the current file, then in the
same places it would have looked for a header requested with
angle brackets. For example, if ‘/usr/include/sys/stat.h’
contains #include "types.h", GCC looks for ‘types.h’ first
in ‘/usr/include/sys’, then in its usual search path.
I have also requested that this be tested using the big-3
simulators to see what they do. Personally I think there
is a lot more experience with this in gcc so I would
prefer to follow them as an example vs other Verilog
vendors. Thoughts, comments or questions gladly accepted.
Cary
|
|
From: Stephen W. <st...@ic...> - 2009-01-30 20:22:02
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We probably should match what the Big-3 do, or at least provide an easy way to get the big-3 behavior. That is the behavior of least surprise for a *Verilog* user, even if us C programmers think they are naive;-) Of course, we need to pin that down precisely, given the back- and-forth we've already experienced. Cary R. wrote: > We have a report in the tracker (pr2533613) requesting a change > to the include search path. I believe we are currently doing > this correctly. What we do almost exactly matches what gcc does. > The request is to make the directory the compiler is running in > be the first directory searched not the directory the file is > located in. The consequence of this is that it is easy and > probably too easy to override any include file. > > We do add the compile directory as the second search path > entry. This is the sole difference from gcc and is basically an > implicit -I. at the head of the search path. I believe the > users problem can be worked around with better use of the -I > flag, so the real question is should we keep the implicit -I. > or should we make this match gcc exactly? > > Here's what cpp-3 says: > > GCC looks for headers requested with #include "file" first > in the directory containing the current file, then in the > same places it would have looked for a header requested with > angle brackets. For example, if ‘/usr/include/sys/stat.h’ > contains #include "types.h", GCC looks for ‘types.h’ first > in ‘/usr/include/sys’, then in its usual search path. > > I have also requested that this be tested using the big-3 > simulators to see what they do. Personally I think there > is a lot more experience with this in gcc so I would > prefer to follow them as an example vs other Verilog > vendors. Thoughts, comments or questions gladly accepted. > > Cary > > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Iverilog-devel mailing list > Ive...@li... > https://lists.sourceforge.net/lists/listinfo/iverilog-devel - -- Steve Williams "The woods are lovely, dark and deep. steve at icarus.com But I have promises to keep, http://www.icarus.com and lines to code before I sleep, http://www.picturel.com And lines to code before I sleep." -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFJg2FgrPt1Sc2b3ikRAgkxAJ9HWLTZpjAqfrKhN2QmdyAQmwBY1gCdFT+3 9Y9djof0Y3tngYGY8ee1FS8= =JQoD -----END PGP SIGNATURE----- |
|
From: Martin W. <mai...@ma...> - 2009-01-30 20:48:39
|
Stephen Williams wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > We probably should match what the Big-3 do, or at least provide > an easy way to get the big-3 behavior. That is the behavior of > least surprise for a *Verilog* user, even if us C programmers > think they are naive;-) > I agree. > Of course, we need to pin that down precisely, given the back- > and-forth we've already experienced. > According to the user manual, NC-Verilog (and Verilog-XL) first searches the current working directory, then the user-specified directories. It does not search the source file directory. To keep everyone happy, I think we should add a compiler configuration option to switch between the two search behaviours. Martin |
|
From: Evan L. <sa2...@cy...> - 2009-01-30 22:48:52
|
Martin Whitaker wrote:
> According to the user manual, NC-Verilog (and Verilog-XL) first searches the
> current working directory, then the user-specified directories. It does not
> search the source file directory.
I've run the code below on Modelsim, cver, and icarus; ModelSim and cver
root the relative path at the CWD, while icarus roots it at the location
of the source file.
I've got to say, though, that rooting at the CWD is pretty stupid. It
means that the behaviour of your program depends on where you run it
from, which doesn't make sense. It also means that the person writing
the code doesn't know in advance how his paths will be interpreted.
The LRM doesn't specify what `include does, but it is specific on
library mappings. This is on p201 of the 2005 LRM:
> Paths that do not begin with / are relative to the directory in which
> the current lib.map file is located.
and, on p202:
> If the file path specification, whether in an include or library
> statement, describes a relative path, it shall be
> relative to the location of the file that contains the file path.
It seems to me that XL got it wrong, everyone else followed them, and
the 2005 LRM adds some confusion. I think you have to go for the XL
behaviour, but perhaps add a switch to fix it.
-Evan
===================================================================
file include-test.v:
--------------------
`include "./include-test2.v"
file include-test2.v:
---------------------
module top;
initial
$display("Hello world!");
endmodule
|
|
From: Jeremy B. <je...@je...> - 2009-01-30 21:01:36
|
On Fri, 2009-01-30 at 12:03 -0800, Cary R. wrote: > We have a report in the tracker (pr2533613) requesting a change > to the include search path. I believe we are currently doing > this correctly. What we do almost exactly matches what gcc does. > The request is to make the directory the compiler is running in > be the first directory searched not the directory the file is > located in. The consequence of this is that it is easy and > probably too easy to override any include file. > > We do add the compile directory as the second search path > entry. This is the sole difference from gcc and is basically an > implicit -I. at the head of the search path. I believe the > users problem can be worked around with better use of the -I > flag, so the real question is should we keep the implicit -I. > or should we make this match gcc exactly? <details of GCC cut> Hi Cary, Apologies if this is a duplicate. I've added this to the bug report and am mirroring it to the discussion list. You are correct about GCC. But.. Icarus Verilog is NOT an alternative to GCC. It is an event-drive HDL simulator and alternative to NC, VCS, ModelSim, VTOC, SpeedCompiler, Verilator etc. So you should look to all the Verilog tools. Where behavior is not clear in IEEE 1364 (the detailed interpretation of `include is not covered), all the manufacturers mimic Verilog-XL (because it was the first HDL simulator). It states: "The `include compiler directive works in the following way: 1. Verilog-XL searches for the file specified by the compiler directive, relative to the current working directory. 2. If the file is not found, Verilog-XL searches the directories specified in the +incdir+ command-line plus option. Verilog-XL searches these directories in the order in which you list them on the command line. 3. If Verilog-XL finds the file specified by the `include compiler directive, it executes the source code in that file as though that code has replaced the ‘include compiler directive. 4. If Verilog-XL searches all the directories that you specified in the +incdir+ command-line plus argument and the file is not found, then the search results in an error and compilation stops." It is essential Icarus Verilog follow the behavior of event driven simulators, or users of NC/VCS/ModelSim will not be able to migrate to this open source alternative. Historically, the difference is probably due to the concept of "golden RTL". Once a design is verified, it becomes "golden" and may not be changed without stringent procedures and checks (with mask sets $1M+, introducing a new bug is something you want to avoid). Engineers starting work on a derivative create a mirror RTL source tree with just the new files. They use the +incdir+ and -y arguments to ensure that the mirror tree is searched first, thereby picking up the modified design. This way all changed RTL is kept isolated in a separate source tree. HTH, Jeremy -- Tel: +44 (1202) 417007 Cell: +44 (7970) 676050 SkypeID: jeremybennett Email: je...@je... Web: www.jeremybennett.com |
|
From: Cary R. <cy...@ya...> - 2009-01-30 22:36:54
Attachments:
inc_example.zip
|
--- On Fri, 1/30/09, Jeremy Bennett <je...@je...> wrote:
> Icarus Verilog is NOT an alternative to GCC. It is an
> event-drive HDL
> simulator and alternative to NC, VCS, ModelSim, VTOC,
> SpeedCompiler,
> Verilator etc. So you should look to all the Verilog tools.
Yes, that's correct, it's just a shame we can't learn from
something that has had much more thought put into the flow.
Enlightenment is good, but it often comes with a costs.
> Where behavior is not clear in IEEE 1364 (the detailed
> interpretation of
> `include is not covered), all the manufacturers mimic
> Verilog-XL
> (because it was the first HDL simulator). It states:
>
> "The `include compiler directive works in the
> following way:
> 1. Verilog-XL searches for the file specified by the
> compiler
> directive, relative to the current working directory.
Is working directory defined to be the directory that
you are running the simulation in? I'm assuming it is,
but I could also argue the working directory could
change with the file being processed. The answer to
this determines which interpretation is correct.
> 2. If the file is not found, Verilog-XL searches the
> directories
> specified in the +incdir+ command-line plus option.
> Verilog-XL searches
> these directories in the order in which you list them on
> the command
> line.
If we assume the working directory is only the directory you
are running the simulation in, what concerns me about this
statement is that the local file directory is not considered.
For example if I run iverilog subdir/code.v and code.v
includes header.vh it will not look for that file in subdir
which to me is completely counter intuitive. Maybe my
programming exposure is getting in the way, but this seems
like incorrect behavior!
> Historically, the difference is probably due to the concept
> of "golden
> RTL". Once a design is verified, it becomes
> "golden" and may not be
> changed without stringent procedures and checks (with mask
> sets $1M+,
> introducing a new bug is something you want to avoid).
> Engineers
> starting work on a derivative create a mirror RTL source
> tree with just
> the new files. They use the +incdir+ and -y arguments to
> ensure that the
> mirror tree is searched first, thereby picking up the
> modified design.
> This way all changed RTL is kept isolated in a separate
> source tree.
I'm very familiar with how this all works. I guess the problem
is that someone created a gold set with all the files in one
place and then because of the local directory first rule we
currently have you can not override any files. This could
have been addressed by putting the include files in a
sub-directory that was then included with +incdir. This
would allow the user to put the new include directory ahead
of the original one and get basically what you wanted. Nested
includes would require copying a few potential unchanged files
to get the search order correct.
I'm willing to change this however it needs to be changed,
but I spent a fair amount of time thinking about why things
should work this way and I want to make sure everyone
understands the trade offs before we decide one way vs the
other.
I disagree with Martin concerning making this an option.
I think we need one true way whatever that is. I will argue
that if we omit the local directory first rule we should
add a -W warning when a file is overridden by a local one.
So if ../gold/one.vh includes two.vh and we use the local
version vs the one in gold we should print a warning that
this files is being overridden. Otherwise you could easily
override a file and get all kinds of strange compile
problems. I think this would only apply to files that are
from the include search path.
I'm attaching an example that can be run to see which way
this is done. Icarus as we all know includes the file
in the sub-directory.
Cary
|
|
From: Jeremy B. <je...@je...> - 2009-01-31 14:56:58
|
On Fri, 2009-01-30 at 14:29 -0800, Cary R. wrote:
> --- On Fri, 1/30/09, Jeremy Bennett <je...@je...> wrote:
>
> > Icarus Verilog is NOT an alternative to GCC. It is an
> > event-drive HDL
> > simulator and alternative to NC, VCS, ModelSim, VTOC,
> > SpeedCompiler,
> > Verilator etc. So you should look to all the Verilog tools.
>
> Yes, that's correct, it's just a shame we can't learn from
> something that has had much more thought put into the flow.
> Enlightenment is good, but it often comes with a costs.
Hi Cary,
Some more thoughts to help your decision making.
I don't think you will win hearts and minds by suggesting hardware
engineers do not think about their flows. In my experience most
organizations have more people working on their hardware CAD flows than
software CAD.
GCC isn't that good a starting place. They changed their include policy
in 4.3.0 (because they hadn't been following the standard). That broke
plenty of software, including SystemC.
> > Where behavior is not clear in IEEE 1364 (the detailed
> > interpretation of
> > `include is not covered), all the manufacturers mimic
> > Verilog-XL
> > (because it was the first HDL simulator). It states:
> >
> > "The `include compiler directive works in the
> > following way:
> > 1. Verilog-XL searches for the file specified by the
> > compiler
> > directive, relative to the current working directory.
>
> Is working directory defined to be the directory that
> you are running the simulation in? I'm assuming it is,
> but I could also argue the working directory could
> change with the file being processed. The answer to
> this determines which interpretation is correct.
Working directory has only one meaning. It means the directory from
which you executed the command. Absolutely no wriggle room here.
<stuff deleted>
>
> If we assume the working directory is only the directory you
> are running the simulation in, what concerns me about this
> statement is that the local file directory is not considered.
> For example if I run iverilog subdir/code.v and code.v
> includes header.vh it will not look for that file in subdir
> which to me is completely counter intuitive. Maybe my
> programming exposure is getting in the way, but this seems
> like incorrect behavior!
But in this case you should run
iverilog +incdir+subdir subdir/code.v.
Or even module hierarchy discovery with:
iverilog -y subdir
Come to think of it why doesn't g++ automatically look for a class
called "Fred" in "Fred.cc". Perhaps GCC could be improved by doing
things the hardware way :-)
As noted hardware engineering is based on pedantic tedium, to avoid
those multi-million dollar respins. You'd better specify explicitly
exactly which source files make up your design and exactly which
directories provide the headers and in which order.
<stuff deleted>
> I'm very familiar with how this all works. I guess the problem
> is that someone created a gold set with all the files in one
> place and then because of the local directory first rule we
> currently have you can not override any files. This could
> have been addressed by putting the include files in a
> sub-directory that was then included with +incdir. This
> would allow the user to put the new include directory ahead
> of the original one and get basically what you wanted. Nested
> includes would require copying a few potential unchanged files
> to get the search order correct.
But that's not the way the world is. 90% (at least) of a new chip is
reuse of existing RTL IP, complete with test benches, scripts, back-end
tools etc.
Icarus Verilog will happily simulate very large designs, but it will be
a big blocker to adoption if that simulation requires a complete
restructuring of existing Verilog source AND propagating that change to
all the other tools using the hierarchy.
I'm currently using Icarus Verilog on a small SoC (150k gates) written
about 8 years ago. The DUT and test bench comprise 1,350 files,
amounting to around 170k lines of Verilog. Restructuring as you suggest
is not just about moving files and directories. I would also need to
rewrite all the test benches and scripts that know where to look for
various files. For example, C code headers (for embedded code) generated
by relative sed scripts on the Verilog headers:
sed < ../../rtl/verilog/wibble.vh > ./wibble-for-c.h ...
Then I'd need to alter all the synthesis tools...
> I'm willing to change this however it needs to be changed,
> but I spent a fair amount of time thinking about why things
> should work this way and I want to make sure everyone
> understands the trade offs before we decide one way vs the
> other.
If the hardware engineers on this mailing list would like to contribute,
their voices would be useful.
> I disagree with Martin concerning making this an option.
> I think we need one true way whatever that is. I will argue
> that if we omit the local directory first rule we should
> add a -W warning when a file is overridden by a local one.
>
> So if ../gold/one.vh includes two.vh and we use the local
> version vs the one in gold we should print a warning that
> this files is being overridden. Otherwise you could easily
> override a file and get all kinds of strange compile
> problems. I think this would only apply to files that are
> from the include search path.
Warning's are fine, but you may want to make this something that has to
be turned on (and you certainly need to be able to turn it off).
Most users will first come to Icarus Verilog with a small example they
know works. Generating warnings about stuff that is silently accepted
with mainstream simulators can be a turn off. It's not the moment to be
persuading potential new users that GCC knows best.
HTH,
Jeremy
--
Tel: +44 (1202) 417007
Cell: +44 (7970) 676050
SkypeID: jeremybennett
Email: je...@je...
Web: www.jeremybennett.com
|
|
From: Cary R. <cy...@ya...> - 2009-01-31 18:26:48
|
--- On Sat, 1/31/09, Jeremy Bennett <je...@je...> wrote:
...
> Working directory has only one meaning. It means the
> directory from
> which you executed the command. Absolutely no wriggle room
> here.
OK then all this is basically a moot point. The local include
stuff needs to go.
> If the hardware engineers on this mailing list would like
> to contribute,
> their voices would be useful.
Most of use here are hardware engineers in one form or another.
I spend most of my time driving an analog simulator. I'm also
responsible for the relatively small digital sections. I code
when needed or for fun.
> Warning's are fine, but you may want to make this
> something that has to
> be turned on (and you certainly need to be able to turn it
> off).
That's how the -W flag works.
I appreciate your input. I think adding a warning is almost
a required enhancement. The whole reason I added the current
functionality is to prevent someone from accidentally
overriding an include file from the include path and if we
are going to remove it I want a safety catch so we can easily
see which files are being overridden. Not doing this requires
significant hand checking and diligence in file naming that
the compiler can easily perform.
So my suggestion is, remove the automatic addition of the
local directory and then look at adding a warning if a
working directory files blocks the inclusion of a search
path file. I think this only needs to be done it the file
doing the include is also in the search path. This allows
working directory files to just use the working files and
not generate a waring even if there is a file name
conflict. Will this satisfy everyone?
Cary
|
|
From: Evan L. <sa2...@cy...> - 2009-02-01 19:29:49
|
Jeremy Bennett wrote: > As noted hardware engineering is based on pedantic tedium, to avoid > those multi-million dollar respins. You'd better specify explicitly > exactly which source files make up your design and exactly which > directories provide the headers and in which order. Sorry, just got to reply to this. This rather implies that XL does it the 'right' way. Well, yes, it does, but only because it *is* XL; that doesn't make it logical, or a good way to do design, hardware or otherwise. Surely it's much more logical that the code *writers* specify exactly where the source code is? This has to be done relative to the location of the source files themselves. It makes no sense to specify file locations relative to wherever someone happens to run the simulation tool from; this is just asking for trouble. The intent must be specified in the code itself. The LRM writers clearly recognised this when they wrote the library mappings section; relative paths in library mappings are relative to the source files, not the place where the tool was run from. They also specified this in the full knowledge of what XL does with `include. As with so much else in Verilog, it is what it is simply because XL did it that way, and not for any good reason. Of course, you have to do what XL does; you may or may not want to add an alternative to 'fix' this. In normal circumstances, it would be stupid to add options to do things differently, but the whole history of Verilog is about fixing things. Look at SystemVerilog, for example. BTW, on the issue of CWD, Unix processes have a defined working directory which can be found from getcwd(), /proc/self/cwd, or whatever (System V's getcwd() executed 'pwd'). I use the libc getcwd() (and _getcwd() on MinGW/win32) to emulate cpp behaviour for Maia. -Evan |
|
From: Cary R. <cy...@ya...> - 2009-02-01 20:23:30
|
--- On Sun, 2/1/09, Evan Lavelle <sa2...@cy...> wrote:
> The LRM writers clearly recognised this when they wrote the
> library
> mappings section; relative paths in library mappings are
> relative to the
> source files, not the place where the tool was run from.
> They also
> specified this in the full knowledge of what XL does with
> `include. As
> with so much else in Verilog, it is what it is simply
> because XL did it
> that way, and not for any good reason.
>
> Of course, you have to do what XL does; you may or may not
> want to add
> an alternative to 'fix' this. In normal
> circumstances, it would be
> stupid to add options to do things differently, but the
> whole history of
> Verilog is about fixing things. Look at SystemVerilog, for
> example.
Unfortunately it's also about under specifying things that
can not be adequately justified, but have become defacto
standards and would break existing code if fixed. This
issue is just the latest example.
I personally think Icarus is more correct, but since this
more correct behavior creates problems with the implicit
standard I don't know if we have much of a choice. With
minor rewriting you could make the original code function
correctly, but like Jeremy has pointed out people really
dislike touching their gold code. It would be trivial to
support both search orders with a flag. The problem is if
the XL behavior is the default is anyone going to use the
enhanced version?
Once we have a consensus or an official edict I'll change
this as needed.
Cary
|
|
From: Steven W. <st...@in...> - 2009-02-02 00:54:49
|
I don't write often to the list - but read it every day. I've had a long interest in Icarus and have been a fan since it's earliest days. Let me relate a little story - when we THOUGHT we found the very first bug in Verilog-XL in the course of creating the first set of tests for the test suite. The bug itself had to do with the how @(posedge clk_vector) should be interpreted (assuming a declaration like input [5:0] clk_vector; ) Icarus (and the standard) set it should be handled as if it was coded @(posedge |clk_vector) - so we dutifully informed Cadence of the bug in XL (and worry rather proud of ourselves in the process ;-) Oh - I should point out that I was working with both James Lee of Verilog Quickstart fame, and for Yatin Travedi (head of the Verilog standards committee. ) at the time. So I had a fair amount of authority (I thought) when we put in the bug report. Cadence's reply was initially amazing to me. They basically set that the committee got it wrong, and XL was how it was suppose to work. End of discussion. Basically - this happens to be how most hardware engineers treat it as well. XL defined the standard. XL is was the proof of concept. It should work how XL works. End of discussion ;-) That's my two cents worth anyway. Steve WIlson Cary R. wrote: > --- On Sun, 2/1/09, Evan Lavelle <sa2...@cy...> wrote: > > >> The LRM writers clearly recognised this when they wrote the >> library >> mappings section; relative paths in library mappings are >> relative to the >> source files, not the place where the tool was run from. >> They also >> specified this in the full knowledge of what XL does with >> `include. As >> with so much else in Verilog, it is what it is simply >> because XL did it >> that way, and not for any good reason. >> >> Of course, you have to do what XL does; you may or may not >> want to add >> an alternative to 'fix' this. In normal >> circumstances, it would be >> stupid to add options to do things differently, but the >> whole history of >> Verilog is about fixing things. Look at SystemVerilog, for >> example. >> > > Unfortunately it's also about under specifying things that > can not be adequately justified, but have become defacto > standards and would break existing code if fixed. This > issue is just the latest example. > > I personally think Icarus is more correct, but since this > more correct behavior creates problems with the implicit > standard I don't know if we have much of a choice. With > minor rewriting you could make the original code function > correctly, but like Jeremy has pointed out people really > dislike touching their gold code. It would be trivial to > support both search orders with a flag. The problem is if > the XL behavior is the default is anyone going to use the > enhanced version? > > Once we have a consensus or an official edict I'll change > this as needed. > > Cary > > > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Iverilog-devel mailing list > Ive...@li... > https://lists.sourceforge.net/lists/listinfo/iverilog-devel > |
|
From: Stefan T. <Ste...@gm...> - 2009-02-04 05:49:56
|
Hi Folks, I guess we all agree that XL's behaviour to have include path relative to the simulator rundir as opposed to the location of the file containing the include is "not so good", but for the sake of legacy and convenience, I'd vote for iverilog to support is as it's default behaviour. Having a switch for use "sane include file behaviour" would be really, really nice, especially when coupled with the following long standing but never filed enhancement request. report all missing +incdir+<relative path from here to where include dir is> when in "sane include file behaviour" mode. This way one can use iverilog in a sane way AND get the benefit of just having to copy/paste the necessary +incdir+ commands in a -f (unforunately -c for iverilog) command file for XL compatibility. Best of both worlds and a way to convert. Stefan -- Jetzt 1 Monat kostenlos! GMX FreeDSL - Telefonanschluss + DSL für nur 17,95 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a |
|
From: Martin W. <mai...@ma...> - 2009-02-04 19:42:13
|
Stefan Thiede wrote: > Hi Folks, > > I guess we all agree that XL's behaviour to have include path relative to > the simulator rundir as opposed to the location of the file containing the > include is "not so good", but for the sake of legacy and convenience, I'd > vote for iverilog to support is as it's default behaviour. > No, I don't think everyone agrees on this. Jeremy has presented a perfectly good rationale for XL's behaviour. > Having a switch for use "sane include file behaviour" would be really, > really nice, especially when coupled with the following long standing but > never filed enhancement request. > But I agree that having a switch to give the user the choice is the best option - with the default behaviour being to mimic XL. Additional (optional) warnings are nice, but shouldn't be allowed to hold up 0.9. Martin |
|
From: Cary R. <cy...@ya...> - 2009-02-04 19:50:48
|
I went back and looked at the original PR that motivated
us to add the local path to the search order and I think
we need to continue to support this as an option. I have
sent a private email to the pr author asking for comments.
As it stands I will add a -g option (-grelative-include)
that will add the local file directory to the search path.
I'm assuming we want this to exactly mimic the functionality
we currently have. If this option is not given or if the
-gno-relative-include option is given we will skip the local
directory. For this case I will add an optional warning if
a local or later include file is shadowed by one earlier in
the search path. Should this be part of -Wall? My current
thought is that it should not be.
I may do this as two different patches. To expedite getting
this fixed for Jeremy.
Does this sound reasonable?
Cary
|
|
From: Jeremy B. <je...@je...> - 2009-02-05 08:25:33
|
On Wed, 2009-02-04 at 11:50 -0800, Cary R. wrote: > I went back and looked at the original PR that motivated > us to add the local path to the search order and I think > we need to continue to support this as an option. I have > sent a private email to the pr author asking for comments. > > As it stands I will add a -g option (-grelative-include) > that will add the local file directory to the search path. > I'm assuming we want this to exactly mimic the functionality > we currently have. If this option is not given or if the > -gno-relative-include option is given we will skip the local > directory. For this case I will add an optional warning if > a local or later include file is shadowed by one earlier in > the search path. Should this be part of -Wall? My current > thought is that it should not be. > > I may do this as two different patches. To expedite getting > this fixed for Jeremy. > > Does this sound reasonable? Hi Cary, This sounds good. Thanks for the work you've put into this. Jeremy -- Tel: +44 (1202) 417007 Cell: +44 (7970) 676050 SkypeID: jeremybennett Email: je...@je... Web: www.jeremybennett.com |
|
From: Cary R. <cy...@ya...> - 2009-02-05 02:06:53
|
A patch has been submitted that makes relative searching off
by default. It can be enabled with the -grelative-include
option to iverilog. I will look at adding a warning about
overridden include files at a later date. Hopefully before
we release V0.9.
Cary
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X