| 1 |
Enrico Weigelt wrote: |
| 2 |
> > and I'm asking myself, why its not done every install, or why we |
| 3 |
> > get ./configure generated in the tar.gz. |
| 4 |
> |
| 5 |
> These arguments I've heared over the years: |
| 6 |
> |
| 7 |
> a) save time and cpu cycles for end users |
| 8 |
> b) get around autotools version conflicts |
| 9 |
> c) we always did so, so why change ? |
| 10 |
|
| 11 |
I think you're missing the point then. The point is obviously to |
| 12 |
allow source packages to compile on a very wide variety of platforms. |
| 13 |
Specifically, the auto* packages should not be needed on the build |
| 14 |
system. This is why configure is included in releases, and tries to |
| 15 |
run on as many different shells as possible. |
| 16 |
|
| 17 |
|
| 18 |
> The best solution, IMHO, would be replacing all these dubious |
| 19 |
> macros by a bunch of carefully written shell functions. |
| 20 |
|
| 21 |
Of course you already know that in fact the macros *are* shell |
| 22 |
functions. Look in a generated configure. They may be unrolled, |
| 23 |
but still. |
| 24 |
|
| 25 |
|
| 26 |
> There would be no generation phase at all. |
| 27 |
|
| 28 |
Generation would be traded for a build-time requirement to have the |
| 29 |
library of shell functions installed on the system. Such a regression |
| 30 |
is not an option. |
| 31 |
|
| 32 |
|
| 33 |
> I've started some hacking on that for zlib, a while ago. Maybe |
| 34 |
> somebody might like to join me ... |
| 35 |
|
| 36 |
It would be interesting to see what you come up with there. IIRC zlib |
| 37 |
is not using full-on autotools though? |
| 38 |
|
| 39 |
Rewriting autoconf to use sh instead of m4 is an interesting idea. I |
| 40 |
think it would make sense to phase out m4. But I also don't think it |
| 41 |
is a strong requirement. |
| 42 |
|
| 43 |
|
| 44 |
> I'd rather propose (on per-package basis) directly maintain the sources |
| 45 |
> (including dist-specific changes) in an own repository, so the whole |
| 46 |
> download+unpack+patch phase is replaced by just a checkout, and things |
| 47 |
> like rebasing dist-specific changes can be done directly via vcs. |
| 48 |
|
| 49 |
Except that it creates a proper fork of every package, which is |
| 50 |
pretty stupid IMO. Yes this happens in practise with patches too, but |
| 51 |
in my view patches are really only temporary fixes until upstream has |
| 52 |
solved the problem better. The purpose of a source-based distribution |
| 53 |
is to use the upstream sources. Some upstreams have significant QA |
| 54 |
which it would be silly to not take full advantage of, by using their |
| 55 |
released archive. |
| 56 |
|
| 57 |
|
| 58 |
//Peter |
Archives