Mail Archives: geda-user/2015/08/23/13:05:02
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:
>> Imo with autotools it's not about "fixing what problems remain". The
>> problems I faced in practice always went down to design issues. This
>> why I decided to try an alternative design.
>
> That's fair enough.
>
>
>> Autotools is very popular. I do realize that many developers and packagers
>> are familiar with the interface it offers. I also do realize the merits of
>> a well known interface. However, I do not think that autotools is a good
>> desing or the interface is particaularly conveninet
>
> I don't know about design, but I find the interface very convenient.
> --prefix and --host in particular. There's a lot of knowledge encoded
> behind --host and while I would like scconfig to support --host I
> don't want you to have to reimplement it all. :\
If we are talking about cross compilation, that's supported by scconfig,
but the whole approach to it is different.
I essentially have a tree of properties (e.g. what's the ldflags for
glib). There are tables binding tree nodes to detection code and there are
dependencies between detections. All in all, you tell it to figure the
ldflags for glib, and it will first look for all dependencies (e.g. cc so
that test programs can be compile) and fill in the values in the tree.
Cross compilation means all the above is really a subtree of a larger
tree. There is a /host subtree and a /target subtree. Whenever you need
something for running your build system (e.g. to generate files), you need
a /host thing, else (e.g. glib's LDFLAGS for compiling the binary to
ship) you need the /target thing.
This is the default setup, and not cross-compiling is the "special case"
when /target is a symlink to /host in the tree. Everything does the same,
you still look for /host things and /target things, but they will always
be detected only once, and are always the same for /host and /target.
I've tested this with some projects, cross-compiling to win32 using mingw
and sometimes wine to run the test programs. Worked well.
>
>
>> or that autotools should have no alternatives.
>
> There are several, I'm not a big fan of either of them, not because
> autotools is so great, but because it is very often good enough, and
> generally more capable than the alternatives.
Yeah, I did check some alternatives too, and didn't like them either. I
then tried to solve the problem using bash, but figured bash itself is not
very easy to port. Then I had a short detour into "what if I don't even
generate Makefiles but have a more clever make" in parallel with scconfig.
I finally settled with the idea that scconfig should depend only on ANSI C
(C89), and I should use it to generate the simplest Makefiles possible so
I don't need any clever make or clever shell or even assume
things about binutils.
>
>
>> look at the actual bloat autotools introduce.
>
> In the source repo there's little to no bloat. configure.ac and
> Makefile.am don't need to be long.
>
>
> In source releases there's the generated code. That can be considered
> bloat or the cost of portability.
>
I meant the source code of autotools included. We were talking about
fixing autotools when it's broken.
My typical problem was that something got detected the wrong way. Wrong
ldfalgs, wrong cflags, things like that. It usually took much time to
figure what exactly went wrong where, then trace it back to m4. Then I
didn't necessarily have the inrfastructure on the target machine to
regenerate the files...
>> If we admit that autotools does not really solve most of the portability
>> issues
>
> I consider autotools+pkg-config to be scaffolding which eases the
> task of writing and maintaining portable source code.
To me, this translates to: "portable as long as you install a few 10
megabytes of unrelated GNU first". It may sound radical, but in this
regard even win32 exe can be considered portable: if you install wine, it
runs. Most of the "exotic" systems I use don't have pkg-config.
>> and it only will make the project work on Linux, some BSDs and
>> maybe, maybe, maybe on windows... Well then, I'd rather have a
>> Makefile.Linux, a Makefile.BSD and a Makefile.win32.
>
> I think it is far too valuable to have a consistent abstraction for
> the toolchain tuple which is upward compatible to have only system-
> specific Makefiles.
Again, I'd agree if it was much smaller and more reasonable.
>> Optimum 1: be it large, complicated and bloated, but then it
>> absolutely must work out of the box on whatever system I have at
>> hand. Optimum 2: be it manually tailored to a given system,
>> support only the 2 or 3 most popular systems, but at least be it
>> small and easy to hack.
>
> Manually tailoring works great as long as there's no need to support
> an internet full of users. I do manual stuff too, and it's great for
> me as it is for you! But it's not a great general solution.
I agree. However, my point is still that in my practice autotools doesn't
support an internet full of users out-of-the-box, only 2..3 common
systems, anything more exotic needs a lot of tweaking. So we did not solve
the problem we wanted.
>
>> I'd happily fix it, if it was about minor implementation problems. But I
>> really believe it's about a few major design issues. I sort of fixed it,
>> by implementing a different design.
>
> I'm interested in how it goes.
The basics are there, and tested in some projects. There are a lot left to
be done yet, tho. Like more CLI options to direct how things should
happen for the cases when the automatism doesn't work.
>
>
>>>> 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?
>>
>> Yeah, I'd ask "why would it break" too, scratching my head over the vt420
>> or the telnet session.
>
> Btw, were your problems with running autotools themselves on the
> exotic systems, or were your problems with running the *output* from
> autotools (configure, Makefile) that were generated elsewhere?
The output. I usually didn't have enouigh infra to run autotools itself.
>> I now have a script that uses ldd to collect all the libs in a directory.
>
> Also check out readelf. ldd recurses on dependencies, which isn't
> neccessarily helpful.
Thanx, will do so. I think I do need recursion here, tho: I need to get a
full list of all .so files ever linked to the main executable.
>
>
>> However, the user may have some of the libs installed,
>
> Fun! It sounds like you're building a package manager. :)
Lol, I hope I don't. I try to keep it simple.
>
>
>> Ohh, and I aim to support doing all this in a simple home directory.
>
> Maybe check out Gentoo prefix.
Nice, thanx.
Btw, my current problem is that after collecting all libs and moving the
pack to another system, gtk complains about gtk 2.x symbols should not be
mixed with gtk3 symbols. On the test system I don't have any version fo
gtk installed and ldd reports no libs used from /usr anyway, so it's
strange.
Regards,
Igor2
- Raw text -