| 1 |
On Mon, Jun 28, 2021 at 11:58 AM Agostino Sarubbo <ago@g.o> wrote: |
| 2 |
> |
| 3 |
> On lunedì 28 giugno 2021 17:07:57 CEST Michael Orlitzky wrote: |
| 4 |
> > If the package declares a dependency on e.g. virtual/c-compiler, ago |
| 5 |
> > would want to re-test it whenever a new version of any compiler is |
| 6 |
> > released that satisfies virtual/c-compiler. Conversely, if the package |
| 7 |
> > doesn't require virtual/c-compiler, we may assume that it doesn't |
| 8 |
> > compile C code, and is not affected by the new version. |
| 9 |
> |
| 10 |
> I need to admit that your solution is more simplest because there is nothing |
| 11 |
> to implement. |
| 12 |
> |
| 13 |
> We can create a new category (like virtual) called tinderbox, then for example |
| 14 |
> we could have: |
| 15 |
> tinderbox/c |
| 16 |
> tinderbox/c++ |
| 17 |
> tinderbox/go |
| 18 |
> |
| 19 |
> and so on. |
| 20 |
> |
| 21 |
> Those tinderbox 'packages' added as DEPEND must not pull a default compiler or |
| 22 |
> so, instead they will not pull anything. |
| 23 |
|
| 24 |
This seems unnecessarily complex. Why not make them REAL virtuals. |
| 25 |
If your package depends on any C compiler then have it pull in |
| 26 |
virtual/c-compiler (or whatever we want to call it). If your package |
| 27 |
depends on gcc explicitly, then just depend on gcc. With the system |
| 28 |
of empty virtuals you provide you then need to have logic for what the |
| 29 |
virtuals "really" mean since they don't actually pull in anything, and |
| 30 |
they're also useless for actual dependency-resolution as a bonus. |
| 31 |
|
| 32 |
> They are there with the purpose of show the output of something like: |
| 33 |
> equery depends tinderbox/c |
| 34 |
|
| 35 |
The problem with this is that if something works with gcc and not with |
| 36 |
clang, and clang changes, you test it anyway, because you have these |
| 37 |
hard-coded definitions of what "c" is. If you use real virtuals, then |
| 38 |
you just find all the reverse deps of clang and that is what you need |
| 39 |
to test, because they're just normal dependencies. |
| 40 |
|
| 41 |
You don't actually have to implement the full removal of the @system |
| 42 |
special logic to do this. You can specify things that are in @system |
| 43 |
as dependencies even if our policies don't currently require it. |
| 44 |
Listing two paths to the same dependency doesn't hurt anything as far |
| 45 |
as I'm aware. |
| 46 |
|
| 47 |
-- |
| 48 |
Rich |
Archives