Mail Archives: geda-user/2015/08/23/10:22:46
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
- Raw text -