On Mon, Jun 28, 2021 at 11:58 AM Agostino Sarubbo <[email protected]> wrote: > > On lunedì 28 giugno 2021 17:07:57 CEST Michael Orlitzky wrote: > > If the package declares a dependency on e.g. virtual/c-compiler, ago > > would want to re-test it whenever a new version of any compiler is > > released that satisfies virtual/c-compiler. Conversely, if the package > > doesn't require virtual/c-compiler, we may assume that it doesn't > > compile C code, and is not affected by the new version. > > I need to admit that your solution is more simplest because there is nothing > to implement. > > We can create a new category (like virtual) called tinderbox, then for example > we could have: > tinderbox/c > tinderbox/c++ > tinderbox/go > > and so on. > > Those tinderbox 'packages' added as DEPEND must not pull a default compiler or > so, instead they will not pull anything.
This seems unnecessarily complex. Why not make them REAL virtuals. If your package depends on any C compiler then have it pull in virtual/c-compiler (or whatever we want to call it). If your package depends on gcc explicitly, then just depend on gcc. With the system of empty virtuals you provide you then need to have logic for what the virtuals "really" mean since they don't actually pull in anything, and they're also useless for actual dependency-resolution as a bonus. > They are there with the purpose of show the output of something like: > equery depends tinderbox/c The problem with this is that if something works with gcc and not with clang, and clang changes, you test it anyway, because you have these hard-coded definitions of what "c" is. If you use real virtuals, then you just find all the reverse deps of clang and that is what you need to test, because they're just normal dependencies. You don't actually have to implement the full removal of the @system special logic to do this. You can specify things that are in @system as dependencies even if our policies don't currently require it. Listing two paths to the same dependency doesn't hurt anything as far as I'm aware. -- Rich
