X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com Message-ID: <20150823142225.5557.qmail@stuge.se> Date: Sun, 23 Aug 2015 16:22:25 +0200 From: "Peter Stuge (peter AT stuge DOT se) [via geda-user AT delorie DOT com]" To: "Peter Stuge \(peter AT stuge DOT se\) \[via geda-user AT delorie DOT com\]" Subject: Re: [geda-user] Antifork Mail-Followup-To: "Peter Stuge (peter AT stuge DOT se) [via geda-user AT delorie DOT com]" References: <55D8D8B8 DOT 7050907 AT jump-ing DOT de> <20150823051355 DOT 30150 DOT qmail AT stuge DOT se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 gedau AT igor2 DOT repo DOT hu wrote: >> gedau AT igor2 DOT repo DOT hu wrote: >>> honestly, did you try to install a different version of glib in >>> your home using autotools and then compile pcb using that version? >> >> Yes. And not just with the native toolchain, but cross toolchains too. > > Out of curiosity, what exactly did you have to type for PCB's ./configure > to find the glib that was installed in your /home and not the glib > installed on your system? Set PKG_CONFIG_LIBDIR so that the /home glib .pc is found before the system one. If scconfig also uses pkg-config that helps compatibility a lot, but it is still only part of the story. >> A large number of package management systems support autotools. It's >> a very round wheel. > > I have experience only with debian's package management system. Since > scconfig offers a ./configure too, it's the same for packaging.> I think > it's more about prejudication: if it's not autotools, it must suck. I'm more pragmatic. What is important is that the interface is compatible and functionality is comparable, but I haven't gotten the impression that you want scconfig to support most autoconf configure options and if you do then you have the problem of always having to chase the other implementation to keep up with their functionality - which is no fun at all. :\ I think it would be much better to spend the effort on fixing what problems remain in autotools instead of essentially rewriting them. > sometimes even without looking. I did look. Not now, but before. Did I misremember? In that case I would like to extend an apology. Even then, without a common interface anything else *is* worse, when a lot of infrastructure is built around the autotools interface. >>> And did it work for the first attempt, without questions raised? >> >> Yes, every time, except for Windows, because of the guile problem. > > My bad experience with autotools comes from 6+ different UNIX systems. .. > Like once I spent days getting bash, screen, subversion and all their > dependencies compiled on a proprietary SysV-like UNIX of the late 90s. Here we are, 15 years later. I also had fun with proprietary systems, but I decided that they are too limited for me and that they waste my time. I don't blame autotools, I blame the proprietary system, so to say. You're probably one of a few who have access to that system so you are in a fairly unique position to improve autotools for it. But I do understand that you don't; the cost/benefit ratio for corner cases isn't great. > The real bad part is when autotools fails, it's hard to see what exactly > went wrong I don't recall having really difficult failures. Maybe I've been lucky. > sometimes megabyte long generated shell scripts don't help at all. Yes, if the generated code is broken that's no fun. But why would it be? > When autotools fails, it's almost always balmed on the project using > autotools. I think that's usually accurate, but of course there are corner cases. > The problem is not of technical nature. The problem is how much risk and > effort my potential user wants to take/invest. I think that's accurate, and it goes hand-in-hand with knowledge about using autotools or another configuration system to build software the desired way. > In my experiment with > pcb-rnd the past month, I figured my typical potential user: > > - doesn't want to install anything as root - not from source, not from > packages; so even if the thing works as ./configure; make; make install, > it doesn't matter Everyone building from source should have seen and learned about the autoconf configure option --prefix > - chroot is virtually unknown these days And not so neccessary. > - virtual machines are known, but I guess the cost of setting up one is > out of reach for my potential users Also not neccessary. > - this results in non-standard installation; but it seems to be unaccepted > that for non-standard installation the user needs to invest some time > learning how to do it Consumers will be consumers. I am mostly a consumer of pcb; that's why I haven't tried pcb-rnd out. pcb does the job for me. > Downloading/watching a video or trying a web page seems to be the > effort users are willing to invest. Yep. > This made me think to try the "unpack this tarball as an user and run > ./start". Yes. See Ubuntu snappy apps AKA snaps. https://developer.ubuntu.com/en/snappy/tutorials/build-snaps/ //Peter