Mail Archives: geda-user/2015/08/23/01:54:27
On Sun, 23 Aug 2015, Peter Stuge (peter AT stuge DOT se) [via geda-user AT delorie DOT com] 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?
>
> 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. Even
if autotools is a bloatware and often fails (see the next paragraph),
people think anything else must be worse, sometimes even without looking.
>
>> 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.
My experience is that autotools fails about 7..8 cases out of 10 when
trying to configure random projects on non-mainstream OS. I am saying
this after compiling some relatively large code. Like once I spent days
getting bash, screen, subversion and all their dependencies compiled on a
proprietary SysV-like UNIX of the late 90s.
Some failures are minor and need small tweaks, others are major.
Autotools works out-of-the-box on Linux, on some mainstream modern BSD
systems and sometimes on windows (if you have enough stuff installed
and/or doing cross compilation), on anything else I've seen it fail too
often.
The real bad part is when autotools fails, it's hard to see what exactly
went wrong and even harder to find out where exactly to fix it. Layers of
m4 and sometimes megabyte long generated shell scripts don't help at all.
When autotools fails, it's almost always balmed on the project using
autotools.
>
>> I will try to compile an as-static-as-possible executable for x86_64
>> Linux. It's not a priority so if it doesn't lead anywhere after a
>> day I will probably give up. But if it works, there'll be a way for
>> new users to try the stuff without having to check out and compile
>> anything (and honestly this seems to be one of the big bottlenecks
>> nowdays - even on Linux).
>
> Source-based distributions have handled this well for a long time,
> but binary distributions are intended primarily for consumption.
>
> With a grown-up source-based package manager it's not a problem.
I think we are not talking about the same thing. I used to have debian
package for pcb-gpmi and all its non-standard dependencies; I have a
debian package for pcb-rnd too. I didn't get any feedback about them so I
assume I was the only user of those. The standard source installation for
all my stuff is ./configure; make; make install. So it's not anything
unusual happening here.
The problem is not of technical nature. The problem is how much risk and
effort my potential user wants to take/invest. 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
- chroot is virtually unknown these days
- virtual machines are known, but I guess the cost of setting up one is
out of reach for my potential users
- 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
- aside of the two testers who kindly volunteered to compile pcb-rnd,
most people don't even consider investing time compiling or installing
anything at all, even without knowing all the above, it's just too much
hassle
- in the same time I got a relatively high number of feedback on the
web-online variant of my footprint generator and on the features I made
screen capture video of. Downloading/watching a video or trying a web page
seems to be the effort users are willing to invest.
This made me think to try the "unpack this tarball as an user and run
./start". It's not the proper solution, just a hack. As an user, I
wouldn't do this, I'd go for a standard installation too. But it seems
this is the "run a program" equivalent of the video/web approach.
Regards,
Igor2
- Raw text -