On Sat, 2013-12-14 at 19:37 +0100, Joris van Rantwijk 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.
I want to get to a point where I have a "stable" edition on ghdl-updates and I believe I'm close; next couple of days will see a few more patches for "low hanging" bugs then I will have a revision that can form the basis for a set of releases; not just Debian, but Mac and others. Development will continue but the "download" versions can be synchronised to that, and only critical patches backported to it. IMO that would be a good starting point for Debian too. > > > * I have completely dropped 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? > > > > On which repository is "changeset ff92a40ea4d9" a searchable item? I > > don't recognise the number... > > Sorry. It is a changeset in my personal clone of your mercurial > repository. I was assuming these numbers remain valid accross clones, > but apparently they don't. As I understand it, if you had pulled all the changesets in sequence they should remain valid; if you have cherry picked, you now have your own branch, and those numbers won't match unless you pull the current head and merge your branch into it. > > If you mean this change set > > https://sourceforge.net/p/ghdl-updates/code/ci/26f177817bffcc140609f5885614f2edb55efb59/ > > I believe the underlying issue IS still there in the compiler; however > > that changeset is corrected by later changes to ortho_lang.c, > > specifically > > https://sourceforge.net/p/ghdl-updates/code/ci/655b2faf0dc82716e3a13be4d4415a25dc4212c1/ > > so that both 32 and 64 bit builds work. > > Yes, I mean that patch. Even if I leave the patch out completely, I can > not reproduce the internal compiler error that we used to have with GCC > 4.7. That's why I think the problem may not exist anymore in GCC 4.8. I recall ghdl built "correctly" without it, but failed to compile selected VHDL files (with some settings, even failing to compile the libs in "Make Install"). I'll review my notes and report if I can reproduce the error now. > Like I said, my current approach requires isolated patches for isolated > issues. This would not be necessary if I could switch to sourceforge > snapshots, but I'm not sure that I can. I will talk to some more > experienced people to figure this out. Like I said, I'd prefer SourceForge, but otherwise I recommend using every patch since https://sourceforge.net/p/ghdl-updates/code/ci/ab36f0a7547fd30a4bc023d208f422617b1ba9f3/ ( = gna.org SVN r150) as an "isolated issue" to stay in sync. Then once I get to my release point, adopt whatever course you feel appropriate until the next release point. Hope this helps. - Brian _______________________________________________ Ghdl-discuss mailing list [email protected] https://mail.gna.org/listinfo/ghdl-discuss
