przebudowywanie ac/am (Re: gphoto2)

[Jakub Bogusz]

On Fri, Oct 03, 2003 at 10:06:25PM +0200, Paweł Gołaszewski wrote:
> On Fri, 3 Oct 2003, Jakub Bogusz wrote:
> > > Dlaczego gphoto2 na HEAD ma wyciete (w stosunku do RA) korzystanie z
> > > ac/am ? Niepotrzebne ?
> > Chodzi o przebudowywanie całości ac/am?
> > Jeśli to nie jest do niczego potrzebne[1], to po co to robić?
> 
> Potrzebne jest, żeby mieć tak naprawdę mniej roboty przy specach na
> dłuższą metę.

Nie ma szans wyjść mniej.
czas na poprawki konieczne + czas na dodanie przebudowania ac/am wszędzie >
czas na poprawki konieczne + czas na dodanie przebudowania tylko tam gdzie
trzeba.

Do tego marnuje się czas builderów - mało znaczące w przypadku Ra, ale
Ac już bardziej.
Ciekawe ile czasu w sumie (dla wszystkich pakietów) zchodzi na
niepotrzebne przebudowywanie ac/am?
Także w sytuacjach, gdy autor użył dokładnie tych samych wersji ac/am,
które mamy...

> Takie żąglowanie włączyć/wyłączyć regeneracjęjest mało
> zachęcająca. Czasem wyjdzie błąd przy regeneracji, ale to jest coraz 
> żadsze, bo ac/am stały się na tyle powszechne i restrykcyjne, że nie jest 
> to już taki problem.

A czasem wyjdzie dużo później, przy używaniu pakietu lub próbie
współpracy z czymś innym. Było kilka takich.
Zresztą wystarczy przegrepować buildlogi - ile z nich zawiera
"sh: (jakieś makro): not found" przy wykonywaniu %configure?
Właśnie na skutek błędnego (niekoniecznie niepotrzebnego, ale w części
przypadków tak) przegenerowania ac/am. Ciekawe czy/kiedy jakieś problemy
będą z tego wychodzić (np. brak jakiejś funkcjonalności w programie).

IMO: jeżeli regenerowanie nie jest wymagane przez poprawki lub błędy
w załączonej wersji (głównie libtoola), to nie ruszać.


Jeszcze tak przy okazji - po co ciągle jest używane "rm -f missing"?
Jeszcze nie napotkałem sytuacji, żeby "automake -f" tego skryptu nie
odświeżyło.


-- 
Jakub Bogusz    http://cyber.cs.net.pl/~qboosh/