Skip to Content.
Sympa Menu

sm-commit - Re: [SM-Commit] GIT changes to devel-llvm-3.0 grimoire by Treeve Jelbert (e0e7f11c911299e0b30d43679291e0c3e608dee7)

sm-commit AT lists.ibiblio.org

Subject: Source Mage code commit list

List archive

Chronological Thread  
  • From: flux <flux AT sourcemage.org>
  • To: sm-commit AT lists.ibiblio.org
  • Subject: Re: [SM-Commit] GIT changes to devel-llvm-3.0 grimoire by Treeve Jelbert (e0e7f11c911299e0b30d43679291e0c3e608dee7)
  • Date: Mon, 13 Feb 2012 03:33:46 +0900

Treeve Jelbert (treeve AT scarlet.be) wrote [12.02.12 21:44]:
> the mesa changes were deliberately done in the the devel-llvm-3.0 branch,
> because I needed to ensure that everything that depends on llvm would build.
>
> This is now true, so I think that this branch can be merged into
> devel-xorg-
> modular
>
> The zsync change has been cherrypicked into master

Testing llvm itself shouldn't require special versions of spells that
llvm does not itself depend on. Why not test llvm against the versions
we already have? The mesalib changes are completely orthogonal to the
changes against llvm here. You could also test llvm against the kernel.
Indeed, you could test llvm against nearly the entire grimoire, as there
are few spells (relatively speaking) that are not C/C++ sources, and
even in other cases you could use llvm as a backend for gcc via the
dragonegg gcc plugin. I don't see a valid reason to have what seems to
be a purely orthogonal update to mesalib tied to an in-testing version
of llvm.

Having these updates in this branch actually prevents this branch from
being merged without bringing in these unrelated changes. Of course the
llvm commits could still be cherry-picked, as zsync was, and the
cherrypicking of zsync is actually indicative of the problem I point out
above.

--
Justin "flux_control" Boffemmyer
Cauldron wizard and general mage
Source Mage GNU/Linux
http://www.sourcemage.org

Attachment: pgpViKVeyqub0.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page