| 1 |
On Tue, Nov 03, 2015 at 08:45:00AM +0100, Justin (jlec) wrote: |
| 2 |
> On 02/11/15 23:38, William Hubbs wrote: |
| 3 |
> > On Mon, Nov 02, 2015 at 09:12:30PM +0100, Justin Lecher (jlec) wrote: |
| 4 |
> >> -----BEGIN PGP SIGNED MESSAGE----- |
| 5 |
> >> Hash: SHA512 |
| 6 |
> >> |
| 7 |
> >> How about a virtual here? |
| 8 |
> > |
| 9 |
> > I don't see that working out to well because the compilers are |
| 10 |
> > completely different from each other. As I said, the reference |
| 11 |
> > implementation of the go language is dev-lang/go and the other one, that |
| 12 |
> > is part of gcc, as I understand it, is not quite as fully developed as |
| 13 |
> > dev-lang/go. |
| 14 |
> > |
| 15 |
> > Thanks, |
| 16 |
> > |
| 17 |
> > William |
| 18 |
> > |
| 19 |
> |
| 20 |
> Hi William, |
| 21 |
> |
| 22 |
> but instead of adding |
| 23 |
> |
| 24 |
> DEPEND="||ยท( |
| 25 |
> >=dev-lang/go-1.4 |
| 26 |
> >=sys-devel/gcc-5.1.0:=[go] |
| 27 |
|
| 28 |
The || dependencies you list should not be needed in most cases. |
| 29 |
|
| 30 |
As has been pointed out in the thread so far, gcc-5 only supports |
| 31 |
go-1.4. dev-lang/go is at 1.5, so really the only thing that should be |
| 32 |
built with gccgo is dev-lang/go. Also, the golang eclasses are designed |
| 33 |
to work with dev-lang/go, so they do not need a dependency on gccgo. |
| 34 |
|
| 35 |
Starting with go-1.5, most of the tools themselves are written in Go, so |
| 36 |
you need an earlier version of Go installed to build it (this is where I |
| 37 |
think I can use gccgo), but I'm not convinced yet about making it a |
| 38 |
virtual. |
| 39 |
|
| 40 |
> Another problem which you have with these split deps is the following. Imagine |
| 41 |
> the user has gcc-5[go] installed, which fullfills the dependency requirement. |
| 42 |
> But she selected gcc-4.9 as the active compiler, which doesn't have go support. |
| 43 |
> The build will fail. For fortran we test in pkg_setup if we have a working |
| 44 |
> fortran compiler present. You would need to do the same for go compiler. |
| 45 |
|
| 46 |
The issue I see is a user could have gcc-5[go] and go-1.6 installed in |
| 47 |
the future. In that case, you would have packages that build with go-1.6 |
| 48 |
but not gcc-5[go], so gcc-5[go] would not fulfill the requirement. |
| 49 |
|
| 50 |
I see gcc-5[go] as a separate Go compiler, but it will always be behind |
| 51 |
dev-lang/go, so you will have things that build with dev-lang/go but not |
| 52 |
gccgo. Also, the commands to do the builds are completely different |
| 53 |
depending on which one you are using. |
| 54 |
|
| 55 |
I'm not sure of a way to deal with those issues in a virtual like you propose. |
| 56 |
|
| 57 |
William |
Archives