Mail Archives: geda-user/2016/09/12/00:16:53
I am not trying to convince anyone about anything, but there are so many
misunderstandings and false assumptions in here... Anyway, my last mail
here, as it really became the usual geda-user flamewar already (sorry that
I though the original question was genuine).
On Sun, 11 Sep 2016, al davis wrote:
> On Sun, 11 Sep 2016 11:38:10 -0800
> "Britton Kerin (britton DOT kerin AT gmail DOT com) [via geda-user AT delorie DOT com]"
> <geda-user AT delorie DOT com> wrote:
>
>> Exactly. Autotools work fine.
Except that it does not work. It's obviously much harder to realize that
on GNU systems...
>> The prospective replacements have all failed
>> because they aren't big enough improvements to be worth switching.
False. Scconfig has big enough improvements and have not failed in any
sense.
>> Most of them have been significant downgrade in some ways, as well as
>> not bothering to provide the same interface.
Shell uses "echo" and C uses "puts". Which one is the downgrade that
didn't bother providing the same interface? Btw, are you using windows? If
now, what you use provides the same interface, right? Becasue that's the
way, everything _must_ provide the same interface, else it's bad...
Not providing the same interface is a good thing, this is how you have
any chance to make improvements and alternatives. I know this idea is far
from most of the posters of this thread, but alternatives are good. Your
personal preference is not the ultimate good solution.
Scconfig is no downgrade and is not bothering to reproduce the bugs of
autotools.
> I agree with all that except "autotools work fine". What it needs
> isn't a complete start-over, but rather a good cleaning, kind of like
> what Tibor is doing to PCB.
Did the same with autotools: figured the design was broken, so I started
the cleaning at the design. This obviously resulted in a different design.
Which means start-over was cheaper.
Also, note: it's pcb-rnd, not PCB. This subtle difference is important: a
big chunk of the cleaning could happen exactly because the burden
of autotools got removed in favor of a simpler, cleaner, more flexible
system.
>
>> When replacement software is worthwhile e.g. git vs. cvs/svn, the switch
>> happens almost immediately.
False assumption. Git is not better than cvs/svn... The truth is: many
projects are using svn or cvs or other VCS than git, because they find
those better. You prefer git. Git is popular. Many projects switched
from whatever to git. Many projects switched to whatever or whatever
else, or just stayed with whatever. Some projects switch from git to
whatever. Git did not replace cvs or svn globally.
Again, the geda-user AT -incompatible idea of alternatives, and that your
personal favorite is not automatically the objectively best, world #1, and
only-thing-everyone-must-use...
> Actually, it's more like an exponential, like the diode curve. There's
> a quiet period, which can be quite long and frustrating, then bang.
Or you just made it up, and the world really works like there are tons of
alternatives. And even if one implementation is not super-popular, or
it doesn't replace the currently popular implementation in all existing
project, that doesn't mean it's bad or the currently popular
implementation is good.
Finally, some facts, just to undo all the false assumptions spread by
non-users in this thread and in general:
- scconfig works fine
- scconfig is a full-featured replacement of autoconf - not
binary-compatible, not bug-compatible. It is an alternative
implementation that fixes both design and implementation issues.
- scconfig has been tested on some old/obscure systems, so it doesn't only
work on modern dekstop Linux with GNU installed.
- of course it doesn't mean that if you pull something even stranger (like
a 15 years old AIX) it is guaranteed to work. It has a very good chance to
work out of the box. In case it fails, its simplicity guarantees that
it can be fixed very fast.
- in fact dependencies required to run scconfig is less numerous than
those of autotools! Scconfig needs an ANSI (c89) C compiler, make (not
necessarily GNU) and shell (works even with windows cmd.exe!).
- scconfig does have cross-compilation support for like 8 years by
now; I recently used it to successfully cross-compile pcb-rnd from a Linux
box to win32 and the resulting executable worked on 3..4 different
systems.
- scconfig promotes simplicity by removing some layers: there's no
autogen.sh, no m4, no generated configure.sh. Both as user and developer
you just run ./configure && make and it just works out of the box.
- scconfig is usually embedded in the project; with all relevant parts of
the source it's still not much bigger than the footprint of autotools. In
return the user or developer doesn't need to install anything, which also
means devs/users won't bump into "I have a different version of autotools
installed and the project-specific m4 magic fails to work with that".
- scconfig does has all features requred for distro packaging - this how I
did local debian packages for pcb-rnd for a long time
Non-users seem to fear to use it (or anything else than autotools) - looks
like sort of a Stockholm-syndrome. Actual users seem to be happy with it:
I often get feedback that pcb-rnd configures and compiles faster. Can't
remember getting any "this is so much painful" report about ./configure
from _actual users_.
So, have fun bashing/praising autootols and bashing alternatives, I'm out
of this thread. In case you want to be constructive: download scconfig (or
pcb-rnd or other scconfig-using projects), try it, if you have any actual
issue with scconfig, please send me a bugreport and then test the fix.
Regards,
Igor2
- Raw text -