On Mon, 09 Jun 2008 20:15:56 -0600 Joe Peterson <[EMAIL PROTECTED]> wrote: > Yes, if everyone is perfect and remembers to do things perfectly > right, there would never be issues in many things, but when you make > something more complicated, there will be more errors.
So we shouldn't ever change anything?
> > Which is why programs that use any major C feature introduced since
> > 1980 use the extension '.cc' or '.cpp'.
>
> So why would not a one-time new extension (e.g. ".eb") do the trick,
> just like ".cc" works for C programs? Unless you are talking about
> needing to specify the EAPI in the file if the more advanced features
> are to be used, but I see nothing wrong with that requirement - it's
> not much different than specifying a slot, keywords, whatever.
Because then we won't be able to change source compatibility again in
the future without introducing yet another new extension.
> > You completely miss the point of the GLEP. We need new extensions
> > precisely because current package managers can't handle future EAPIs
> > cleanly, and we need to carry on using new extensions because
> > otherwise we restrict what future EAPIs can do.
>
> No, I get that. But once you develop the concept of an EAPI, the very
> next package manager version can be aware of it and check the EAPI of
> an ebuild. If the ebuild specifies none, then it is old-style. If it
> specifies one that is unknown or newer than what that package manager
> version knows it can handle, it can handle that case (ignore it or
> whatever). I don't see why you need to keep bumping the
> filename/extension every time it changes from that point forward.
Because the package manager doesn't know how to extract the EAPI from
ebuilds whose EAPI it doesn't support. For example, an EAPI 2 ebuild
might look like this:
require mypackage using ANIMAL="monkey"
How do current package managers understand that the EAPI there is 2?
> >> But what users *really* don't care about is EAPIs, and this GLEP
> >> would expose that technical detail to them in a very blatent way.
> >
> > Anyone who cares about ebuilds at a file level has to care about
> > EAPIs.
>
> Not really. A typical user does not need to know about EAPIs at all,
> but he might want to peruse the portage tree to look for ebuilds. He
> might also want to grep for KEYWORDS or whatever. The user can delve
> into it as much as needed or desired, but if there are these
> mysterious EAPI numbers tacked onto the extensions, then it's an
> added complication that is not important to all users.
The typical user should be using a tool to query that sort of thing.
> >> Along those lines, as I've said before, migrating to a new
> >> extension, *one-time*, as a solution to this, although not
> >> optimal, would be far more satisfactory than introducing a series
> >> of ever-changing extensions.
> >
> > No it won't. It means future EAPIs will be restricted to some
> > particular source format.
>
> I assume you mean that EAPI needs to be in the file - again, is this
> bad? Many file formats specify a file format version as part of the
> file.
It's a pain in the ass, because it means no introducing new global
scope functions and no changing behaviour of existing global scope
functions.
Most file formats don't have to deal with the compatibility issues that
we do. For example, try feeding this C++ program to a C++0x compiler:
void foo(int x)
{
auto bool requires(x == 1);
}
Or this C++0x program to a C++ compiler:
template <std::Regular T_>
T__ && foo(T_ x)
{
std::list<std::list<T_>> l;
return x;
}
In both cases, you get user visible messy errors. That's not something
we have the luxury of being able to do.
--
Ciaran McCreesh
signature.asc
Description: PGP signature
