On 15 Dec 2013, at 7:37 am, Joris van Rantwijk <[email protected]> wrote:
> On 2013-12-14, Brian Drummond wrote: >> I would strongly advise that either you take the Sourceforge >> repository, or if you must keep gna.org, that you take the entire set >> of recent patches from Sourceforge as a single step rather than >> selecting a subset of them. Otherwise there is a danger of building >> an inconsistent version and reintroducing incompatibilities. > > It is clear that you are doing good and sorely needed work, and > Sourceforge is the place where things are happening right now. > > However, Debian packages are not normally supposed to track > development; they are supposed to contain stable, released software. > So I will have to figure out a way to keep the Debian package on the > stable branch of GHDL, without going all the way back to 0.29. Brian is in control of ghdl releases. If he needs to do something to make the ghdl release system compatible with Debian releases, now is the time to do it. In case you can't tell doing so is very important to the ghdl developers. I don't expect the as now envisioned and unimplemented ghdl-0.30 to be useful to Debian, which says the easiest thing might to be to deprecate the un-implemented release and call the next one 0.30. Brian has been responsible for every revision to the code base since svn -r150 on gna.org. I'd imagine his jump to 0.31 intended to delineate his contributions from Tristan's. Brian, Tristan and I have had email exchanges on the suitability of venues and have agreed SourceForge is suitable for purpose. The initial purpose was to be able to deliver a current ghdl to Linux distributions with requirements to target specific gcc releases. Due to inability to effect releases on gna.org it would seem prudent to move all our development efforts. Brian and I have kicked around the issues, bug reporting migration, coming up with release testing incorporable with ghdl as a vhdl language front end to gcc, wikis, discussion groups etc. Your views are solicited. > An alternative is to switch to Brians's sourceforge repository as > upstream baseline. However I don't want to do that unless there is > consensus within the GHDL community that Sourceforge is THE new upstream > repository. Without parsing 'upstream baseline' or 'upstream repository', ghdl-updates on SourceForge reflects the current state of ghdl development by all active ghdl developers. I would consider it the current baseline and it is not being solely used for upstream delivery. We will shortly being doing binary releases there as well as release source snapshots. > Finally, some specific comments on the current Sourceforge patch set: > * I have completely dropped changeset ff92a40ea4d9 which was required > under gcc-4.7 to avoid an internal compiler error on 64 bit. It seems > that this patch is no longer needed with gcc-4.8. Brian, do you agree? > > * With regard to the Start_Choice function, I'm still using your > original patch which adds a Value parameter to the function. Passing > this context as a parameter seems to me fundamentally cleaner than > passing it through a static variable. > > * There is an "OSVVM" patch in changeset 5594d173a2d3 wich looks > intrusive and I don't understand its purpose. Could you provide a > reference to a bug report or further information? The specific solution to all of this might be for Brian to release as 0.30 (as soon as practical) on SourceForge, . There has been no intervening 0.30 release. (And that likely deserves italics). I'd think it unwise to patch away anything to do with Start_Choice casually, Brian's back out reflects continued support for the ghdl mcode version. The gcc front end version of ghdl doesn't fully embrace the entire definition of ghdl, and as Brian has noted there's experimental support for an llvm version that's of great interest. The collision between these aspects is under the ghdl developer control (and we welcome volunteers to participate). We'd like to develop a ghdl view of the future. Today there are three active ghdl developers (for suitable definitions of 'active') and Tristan, who is consumed by his regular employment. Tristan has agreed with my assessment of the need and Brian is in charge. Mind, I had to convince Brian first. He both limits my involvement (meddling) as well as provides and effective goad (e.g. the gcc front end build for OS X). The good news is I can focus on VHDL language issues more fully. > I would love to know Tristan's view on the future of the Gna > repository. Are we in principle still working towards an upcoming > release of GHDL 0.30? Tristan can be contacted at his employment email address. If Brian is willing to call it 0.30 then yes, we are working toward an upcoming release of ghdl-0.30. I really like the reference to Dùn Omhain, though: ghdl --version GHDL 0.31dev (20132311) [Dunoon edition] Compiled with GNAT Version: GPL 2013 (20130314) GCC back-end code generator Written by Tristan Gingold. _______________________________________________ Ghdl-discuss mailing list [email protected] https://mail.gna.org/listinfo/ghdl-discuss
