[Bug 468516] Review Request: verilator - A fast simulator of synthesizable Verilog HDL

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=468516





--- Comment #27 from Lane <dirjud at gmail.com>  2009-01-10 17:37:49 EDT ---
(In reply to comment #26)
> 
> in file (of verilator) src/V3Options.cpp: 
> 
> && !V3Options::fileStatNormal(var+"/src/systemperl.h")) {
> 
> if you remove /src, I believe it should pull systemperl.h from
> perl-SystemPerl-devel. Can you check if please ?

This is not a sufficient solution.  There are a additional files that verilator
pulls from system perl when you turn on tracing that occur during the
simulation build.  I am not in favor of the approach you are proposing here for
the following reasons:

- Neither of us have enough background with the complete scope of verilator or
system-perl to know how far such a change would reach.  I can see this causing
unforeseen bugs that reach into tools even beyond verilator.  In addition to
trying to find all places that verilator references the src/ directory, people
likely have tools beyond verilator that use the systemperl files in the src/
directory (we have one, for example).

- This puts added burden of maintenance on us as the packagers.  Everytime a
new release of verilator and system-perl come out we will have to verify our
patch(s) are still valid and verify that any additional functionality added in
the new releases is not broken.  I prefer to stay as close to upstream as
possible as the upstream project is much broader than my limited use of it.  I
use the tool for verilog simulation, but the tool is much broader than that.  I
feel inadequate putting my stamp that a change such a seemingly benign change
is not problematic.

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.