X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com Date: Mon, 12 Sep 2016 06:28:48 +0200 (CEST) X-X-Sender: igor2 AT igor2priv To: geda-user AT delorie DOT com X-Debug: to=geda-user AT delorie DOT com from="gedau AT igor2 DOT repo DOT hu" From: gedau AT igor2 DOT repo DOT hu Subject: Re: [geda-user] gnet-spice-noqsi documentation In-Reply-To: <20160911221915.160b7b15@floyd.freeelectron.net> Message-ID: References: <8885DFA6-76D0-4A2B-B7BE-C1BD9AFFCDD3 AT noqsi DOT com> <20160906171850 DOT 760f1845663014bb2717461d AT gmail DOT com> <20160910203651 DOT 3e03a6ea AT floyd DOT freeelectron DOT net> <20160911085548 DOT 3ff10379 AT floyd DOT freeelectron DOT net> <20160911221915 DOT 160b7b15 AT floyd DOT freeelectron DOT net> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Reply-To: geda-user AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: geda-user AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk 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]" > 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