On Thursday 13 January 2011, Bob Friesenhahn wrote:
> On Wed, 12 Jan 2011, Stefano Lattarini wrote:
> >
> > Those you list above are very good *practical* reasons not to use quagmire
> > (and the very fact that it took me 3 minutes to find that page with google
> > was IMHO already a clear indicator that the project is dead in practice).
> >
> > The "answer" I was speaking about would have been concerned with why I think
> > that the quagmire *design* and *roadmap* are broken (even ignoring its "less
> > than excellent" developement status).
>
> We should give Quagmire some respect since it is written by the
> original author of Automake, who did quite a good job with Automake.
> It is wrong to think that lack of popularity means that the software
> is not in effective use somewhere or is woefully incompete. Only
> analysis or real-world testing can show how effective the package is.
>
Sorry, I really, really didn't mean to show a lack of respect to the
project.
Let me restate what my points are:
[1] Quagmire is not being developed anymore. And the very fact that
it took me some time just to find its website with google likely
implies that it's used by at most very few projects, and taken
into consideration by at most very very few developers. These are
facts IMHO; and even if Quagmire were to already have a superb
design and the most beatiful codebase in the world, well, that
wouldn't change these facts (sadly and unfortunately).
[2] *I think* (as a matter of personal opinion) that planning to
conflate automake and libtool (and maybe later even autoconf) in
a single project is an error. This, and only this, was the
"design error" I was speaking about (sorry for not having been
clearer about this before, I really really should have been, so
I apologize). On the other hand, I find many of ideas outlined
in the Quagmire README sensible and nice for what concerns the
substitution, re-implementation or improvement over purely
automake features.
[3] IMVHO Automake have had its success because it was the first
project to fill an existing gap (offering an higher-level
make-based "language" with the GNU coding standards in mind),
and because it was adopted from day 0 by some (and after a
short time many) GNU packages. Since Automake's niche is so
well occupied by Automake itself, any potential competitor
should strive to obtain a very very high degree of compatibility
to stand any real chance "against" Automake, bacause people are
(rightly I'd say) reluctant and wary of abandoning something
well-knonw, well-tested, and that works well today, for something
partially incompatible, more unstable, less widespread, and less
documented (as any younger project invariably is), only because
this new project is (or should be) cleaner and *could* end up
working better (even much better) "in the future" (BTW, what
doesn "future" means? One month? One year? Ten?).
This is the "roadmap" error of Quagmire I was speaking about: if it
doesn't start by being 99% automake-compatible from the beginning,
*I think* it won't take off, no matter how much better and cleaner
and easy to use it is. That's a pity, and I don't like things
being this way, but they are nonetheless.
[ Note: even if motivated, this is just my opinion, and I don't
claim it's an objective truth. But the fact that Quagmire
failed to take off despite being written by the person who's
probably the most outstanding Automake contributor shows IMHO
how that opinion deserves at least some credit ].
> However, it is not Automake.
>
Anyway, I think I could make amend of my careless (and apparently
down-putting, even if this wasn't intended) comments by downloading
and trying out Quagmire. There's surely a lot to be learnt from it.
> Bob
>
Regards,
Stefano
