X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Message-ID: <20150823162405.14422.qmail@stuge.se>
Date: Sun, 23 Aug 2015 18:24:05 +0200
From: "Peter Stuge (peter AT stuge DOT se) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To: "Peter Stuge \(peter AT stuge DOT se\) \[via geda-user AT delorie DOT com\]" <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]" <geda-user AT delorie DOT com>
References: <55D8D8B8 DOT 7050907 AT jump-ing DOT de> <CAM2RGhSZ1vi_DFKqZdZYxhto4ZaXLLscBt5m5kk+PH2ZoYW_vw AT mail DOT gmail DOT com> <alpine DOT DEB DOT 2 DOT 00 DOT 1508230609370 DOT 6924 AT igor2priv> <20150823051355 DOT 30150 DOT qmail AT stuge DOT se> <alpine DOT DEB DOT 2 DOT 00 DOT 1508230728050 DOT 6924 AT igor2priv> <20150823142225 DOT 5557 DOT qmail AT stuge DOT se> <alpine DOT DEB DOT 2 DOT 00 DOT 1508231634400 DOT 6924 AT igor2priv>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.00.1508231634400.6924@igor2priv>
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:
> 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. :\


> 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.


> 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.


> 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.


> 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.

But there's nothing wrong with system-specific Makefiles per se, in
particular for supporting limited (often proprietary) platforms and
development environments. I e.g. use both autotools *and* have an
Nmakefile for MS Visual toolchain, if I want to support that at all.


> 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'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.


>>> 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?


> I think it goes far beyond the build system. My recent impression is that 
> just checking out code from VCS or downloading a tarball and compiling and 
> installing from source are already show stopper for many users.
>
> I didn't feel this, uhm, 5 years ago. Don't know what's changed since, 
> maybe the app-store thing?

I think there are just more users now.


>> Yes. See Ubuntu snappy apps AKA snaps.
>>
>> https://developer.ubuntu.com/en/snappy/tutorials/build-snaps/
>
> Nice. Some ideas are similar to the simplicity of some BSD systems' 
> packaing (where a package is just a tarball you unpack to /); some ideas 
> are like /opt in FHS.

And Mac OS X .app folders.


> 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.


> However, the user may have some of the libs installed,

Fun! It sounds like you're building a package manager. :)


> Ohh, and I aim to support doing all this in a simple home directory.

Maybe check out Gentoo prefix.


//Peter