zebra.spec

[Tomasz Kłoczko]

On Sun, 16 May 1999, Artur Frysiak wrote:
[..]
> > Tak czy inaczej IMHO można podejść do tego automatycznie to znaczy już
> > teraz wręcz hurtem podmienić w specach /usr/man i /usr/share/man na
> > %{_mandir}, /usr/bin na %{_bindir}, /usr/info i /usr/share/info na
> > %{_infodir} tak jak zrobiłeś hurtem zamieniając "./configure" na
> > "./configure %{_target}" itd. ..
> 
> Ja bym proponował rozbudować %configure do:
> CFLAGS="$CFLAGS $RPM_OPT_FLAGS" \
> CXXFLAGS="$CXXFLAGS $RPM_OPT_FLAGS" \
> FFLAGS="$FFLAGS $RPM_OPT_FLAGS" \
> ./configure \
> 	--target=%{_target_platform} \
> 	--host=%{_host_alias} \
> 	--prefix=%{_prefix} \
> 	--exec-prefix=%{_exec_prefix} \
> 	--bindir=%{_bindir} \
> 	--sbindir=%{_sbindir} \
> 	--sysconfdir=%{_sysconfdir} \
> 	--datadir=%{_datadir} \
> 	--includedir=%{_includedir} \
> 	--libdir=%{_libdir} \
> 	--libexecdir=%{_libexecdir} \
> 	--localstatedir=%{_localstatedir} \
> 	--sharedstatedir=%{_sharestatedir} \
> 	--mandir=%{_mandir} \
> 	--infodir=%{_infodir} 
> 
> Wszystkie te makra są już poustawiane w macros.
> Wystarczy wtedy zrobić:
> %{configure}
> i po problemie (no może wcześniej autoconf). Jeśli nie ma sprzeciwów
> to wysyłam takie macro na rpm-list do ogólnej akceptacji i włączenia
> do dystrybucji.

Nie wiem czy to nie będzie za dużo. Chodzi o to, że faktycznie wszystkie
te ścieżki można ustawiać poprzez domyślny interfejs jaki tworzy autoconf
dla całego schematu budowania aplikacji. Niemniej schemat to jedno, a jego
poprawne używanie to drugie. Często zdaża się, że maintainerzy czy autorzy
konkretnych poprawek nie widzą szczególnej różnycy w używaniu datadir,
libdir czy sharedstatedir .. tak jakby to było obojetne. O ile z takimi
rzeczami jak bindir, sbindir, includedir, mandir czy infodir nie ma w
zasadzie kłopotu i jest to poprawnie używane to z rozróżnianiem
exec-prefix i prefix czy jest już ciężej. Można tu podejść na dwa sposoby:
- pierwszy: elastyczny uzywający tylko potrzebnego podzbióru powyższego
  wykorzystywany tylko na potrzeby osiągnięcia poprawnego
  rozrzucenia poszczególnych plików po właściwych katalogach,
- drugi: nazwałbym go idelistycznym lub idealnym polegającym na używaniu w
  całości powyższego schematu z wykonywaniem przez nas koniecznych korekt
  sposobu użycia wsztstkich definicji jakie dostarcza autoconf,
  poprawiającym potknięcia autorów configure.in.

Pierwszy sposób wydaje mi się pragmatyczny w podejściu, a na drugi możemy
nie mieć czasu lub możemy nie chcieć go poświęcać (robimy raczej pakiety,
a nie poprawiamy zródła do formy idealnej choć jedno z drugim częśto idzie
w parze). Faktem jest, że używanie powyższego wcale nie musiałoby być
obligatoryjne (i to zapewne miałeś na myśli przedstawiając powyższy
schemat), a wzbogacenie  już używanego makra %configure nadałoby mu
włąściwy sens niemniej obawiam się czy wszystki obecne użycia tego makra
wytrzymają tą zmianę.

W sumie byłbym bardziej za zbiorem zaleceń opierających się o powyższy
schemat i/lub jego maksymalne wykorzystanie.

W sumie nie jestem chyba w stanie ocenić ewentualną skalę poprawek w tym
co mamy pod kontem powyższego (dotąd jakoś nie było potrzeby zastanawiania
się nad tak maksymalnym wykorzystywaniem autoconf, bo w sasadzie
.configure używało się w większości przypadków "z palca", a tutaj ludziom
nigdy nie chciało się pisać litanii parametrów).

Jak oceniasz .. jak duża może być skala koniecznych korekt wprowadzenie
powyższego ? Czy może tylko mi się zdaje, że takie poprawki wogóle będą
potrzebne ?

Jeszcze jedno .. powyższy schemat nie rozróżnia aplikacji z prefixem /usr
i /usr/X11R6 co też może utrudniać maksymalnie szerokie używanie makra
%configure w powyższej formie.

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek w rudy.mif.pg.gda.pl*