🚀 go-pugleaf

On Thu, 21 Mar 2013 21:47:15 +0100,
Sebastian Biały <heby@poczta.onet.pl> wrote:
> Takie problem: posiadam pewna aplikację którą muszę zbudować 
> wielokrotnie za kazdym razem zmieniając pewną definicję. Jest to 
> konkretnie częstotliwość kwarcu.
>
> Efektem czego ląduje z: kilkudziesięcioma odmianami plików .o, 
> kilkunastoma plikami .elf.
>
> Taka praca dla make jest nienaturalna, raz wygenerowane pliki nie będą 
> się chciały kompilować ponownie. A tutaj muszą się obligatoryjnie 
> przebudować kilka razy.
>
> Z drugiej strony wole unikać dodawania do nazwy pliku ${FREQ} tworząc 
> main-1157200.o, bo to znowu nie jest konsystentne z make i jego main.c 
> -> main.o. Może należało by to wsadzić w katalog ${FREQ}?
>
> Jak to poprawnie rozwiązać? Zalożenie jest takie, że zmiana main.c 
> spowoduje N-krotne przebudowanie main.o dla każdego FREQ z jakiejś 
> listy. Lista jest "statyczna", tj jest gdzieś w zaasięgu wzroku make.
>
> Gorzej: bardzo możliwe że ten parametr to jeden z wielu ktore mogly by 
> się zmieniać. Mam więc K-parametrów. Jak to zrobić bardziej ogolnie?
>
> Ze względu na niskopoziomowe dłubanie w kompilatorze (dekompilacje, 
> skrypty linkujące i takie tam) interesują mnie raczej rozwiązania 
> pozwalające kontrolować każdy element procesu. I oczywiście to jest 
> kroskompilacja na nietypową architekturę...

To czego szukasz nazywa się "out of source(s) build".
Technicznie jest to dość skomplikowane i eleganckie rozwiązanie
to zestaw makefile'i (najlepiej z configure.ac) na kila tysięcy linii.
CMake również umożliwia "out of sources build".

Jeżeli chodzi o teorię to build odpala się z pustego katalogu
w którym jest automatycznie tworzona struktura katalogów
w której umieszczane są pliki wynikowe.

W moim prywatnym build systemie mam tak że wywołanie make ${TARGET}
automatycznie tworzy katalog build/${TARGET/ a w nim strukturę katalogów
analogiczną do tej z kodu źródłowego i w niej umieszcza pliki wynikowe.

Czyli po wywołaniu

$ make debug release ... ...

mam strukturę:

build/
  debug/
    dir1/
      obj1.o
      obj2.o
    dir2/
      obj1.o
		exec
  release/
    dir1/
      obj1.o
      obj2.o
    dir2/
      obj1.o
		exec
  ...

I tak dalej.

-- 
  Huginn
GCS d? s: a C++$() UBLS++++$ P++ L++++$ E---
W+(-) N++ w-- O M- V- PS+ PE++ Y PGP-
t--- 5-- X- R !tv b++ DI+++ D+ G e* h r++ y**

Dnia Thu, 21 Mar 2013 22:52:04 +0000, Marcin Konarski wyszeptal:

> To czego szukasz nazywa się "out of source(s) build".
> Technicznie jest to dość skomplikowane i eleganckie rozwiązanie
> to zestaw makefile'i (najlepiej z configure.ac) na kila tysięcy linii.
> CMake również umożliwia "out of sources build".

Technicznie to nie jest strudne i nie wymaga tysięcy linii, ale 
zapytałbym najpierw na ile znasz make.

Zacząłbym czytanie manuala od elementów w make, które generują
framenty Makefile w samym Makefile (w locie, takie "makra" 
powiedzmy.

Wtedy całą kompilację wrzuca się w takie "makra", pojawiają
się wtedy $$ i inne nieczytelne rzeczy, z góry mówię
że to nie wygląda dobrze, ale potem takie makro
wykonuje się w pętli (for ...) dla parametrów i efekt jest taki,
jakbyś dla każdej kombinacji parametrów miał osobny fragment
Makefile po inteligentym c-c c-v, co za piszącego robi
sam make. Z tego powstaje jeden Makefile, z targetami, 
zależnościami itd., oczywiście nie jako plik tylko
podczas budowania.

Mówię o nieczęsto używanym feature, i debugowanie generowanych
targetów wymaga kilku sztuczek, ale właśnie w takim celu
powstała ta część make.

-- 
Edek

On 2013-03-21 23:52, Marcin Konarski wrote:
> To czego szukasz nazywa się "out of source(s) build".

Używam tego od zawsze, ponieważ nienawidzę burdelu w źrodłach. Zawsze 
targety znajdują się poza src.

> $ make debug release ... ...

Nie. make foo. I powstaje *kilka* foo z różnymi #define. Coś jak 
boostbuild tylko ja mam. Nie chcę jawnie pokazywac targetów. To tak jak 
gdyby w make było coś na kształt:

for( param in FOO,BAR )
{
all:
   ... -DPARAM=$param
}

On 2013-03-22 09:56, Sebastian Biały wrote:
> Coś jak
> boostbuild tylko ja mam.

... #define.

On 22.03.2013 09:56, Sebastian Biały wrote:
> On 2013-03-21 23:52, Marcin Konarski wrote:
>> To czego szukasz nazywa się "out of source(s) build".
>
> Używam tego od zawsze, ponieważ nienawidzę burdelu w źrodłach. Zawsze
> targety znajdują się poza src.
>
>> $ make debug release ... ...
>
> Nie. make foo. I powstaje *kilka* foo z różnymi #define. Coś jak
> boostbuild tylko ja mam. Nie chcę jawnie pokazywac targetów. To tak jak
> gdyby w make było coś na kształt:
>
> for( param in FOO,BAR )
> {
> all:
> ... -DPARAM=$param
> }

Dawno nie używałem make i w związku z tym nie pamiętam dokładnie składni 
for, ale co stoi na przeszkodzie żeby zrobić tak (make pseudokod):

   for (param in FOO,BAR) {
	make -DPARAM=$param clean all
  	cp plik-wynikowy bezpieczne/miejsce/$param
   }
?

Poza tym, można taką pętelkę machnąć w bashu.

On 2013-03-22 10:27, m wrote:
> for (param in FOO,BAR) {
> make -DPARAM=$param clean all
> cp plik-wynikowy bezpieczne/miejsce/$param
> }
> ?

Katastrofa, rekompilacja za każdym razem.

> Poza tym, można taką pętelkę machnąć w bashu.

Nie. Szukam make-only rozwiązania.

On 22.03.2013 11:55, Sebastian Biały wrote:
> On 2013-03-22 10:27, m wrote:
>> for (param in FOO,BAR) {
>> make -DPARAM=$param clean all
>> cp plik-wynikowy bezpieczne/miejsce/$param
>> }
>> ?
>
> Katastrofa, rekompilacja za każdym razem.

No zaraz, a jak chcesz bez rekompilacji?

Jeżeli chodzi o to że tylko jeden plik .o będzie dotknięty definicjami , 
to spróbuj rm odpowiedni-plik.o && make -DPARAM all zamiast make -DPARAM 
clean all.

p. m.

On 2013-03-22 12:50, m wrote:
>> Katastrofa, rekompilacja za każdym razem.
> No zaraz, a jak chcesz bez rekompilacji?

Normalnie, make foo. I odstaje *kilka* foo.elf z różnymi #define.

> Jeżeli chodzi o to że tylko jeden plik .o będzie dotknięty definicjami

Nie ma takiego założenia.

> to spróbuj rm odpowiedni-plik.o && make -DPARAM all zamiast make -DPARAM
> clean all.

Katastrofa, rekompilacja.

Gdybym chciał rekompilować to bym się nie bawił w make tylko pojechał 
gcc z basha.

Szukam rozwiązania które *działa* czyli zawiera rownież wszelkie cechy 
make takie jak śledzenie zależności i rekompilacja tylko tam gdzie trzeba.

On 22.03.2013 12:55, Sebastian Biały wrote:
> On 2013-03-22 12:50, m wrote:
>>> Katastrofa, rekompilacja za każdym razem.
>> No zaraz, a jak chcesz bez rekompilacji?
>
> Normalnie, make foo. I odstaje *kilka* foo.elf z różnymi #define.

Jakie konkretnie te foo.elf , skoro przecież założenie wstępne jest 
takie, że nie robisz wielu plików o róznych nazwach dla jednego .c

>
>> Jeżeli chodzi o to że tylko jeden plik .o będzie dotknięty definicjami
>
> Nie ma takiego założenia.
>
>> to spróbuj rm odpowiedni-plik.o && make -DPARAM all zamiast make -DPARAM
>> clean all.
>
> Katastrofa, rekompilacja.
>
> Gdybym chciał rekompilować to bym się nie bawił w make tylko pojechał
> gcc z basha.
>
> Szukam rozwiązania które *działa* czyli zawiera rownież wszelkie cechy
> make takie jak śledzenie zależności i rekompilacja tylko tam gdzie trzeba.

Jeżeli zakładamy, że wszystkie pliki mogą używać definicji, to z 
założenia wszystkie trzeba przekompilować. Co byś nie kombinował i tak 
skończysz przy rekompilacji.

p. m.

On 2013-03-22 13:04, m wrote:
>>>> Katastrofa, rekompilacja za każdym razem.
>>> No zaraz, a jak chcesz bez rekompilacji?
>> Normalnie, make foo. I odstaje *kilka* foo.elf z różnymi #define.
> Jakie konkretnie te foo.elf , skoro przecież założenie wstępne jest
> takie, że nie robisz wielu plików o róznych nazwach dla jednego .c

Jak to nie :)? Dostaje wiele elfów, plików .o, .a itd.

> Jeżeli zakładamy, że wszystkie pliki mogą używać definicji, to z
> założenia wszystkie trzeba przekompilować. Co byś nie kombinował i tak
> skończysz przy rekompilacji.

Nie. Jeśli plik main-1234.o jest nowszy niz main.c to nie rekompiluje. 
Nie wiem dlaczego to miało by być w koncepcji problemem. To prosty graf 
kiedy z jednego pliku .c powstaje kilka plików .o ale każdy z nich jest 
prawidłowo oznakowany datą z godnie z regulami sztuki make.

Przypominam że #define nie są przypadkowe tylko są "statycznie znane" 
innymi slowy liczba ścieżek jest znana i powtarzalna pomiedzy odpalniami 
make.

On 22.03.2013 11:55, Sebastian Biały wrote:
> On 2013-03-22 10:27, m wrote:
>> for (param in FOO,BAR) {
>> make -DPARAM=$param clean all
>> cp plik-wynikowy bezpieczne/miejsce/$param
>> }
>> ?
>
> Katastrofa, rekompilacja za każdym razem.
>
>> Poza tym, można taką pętelkę machnąć w bashu.
>
> Nie. Szukam make-only rozwiązania.

Głupie założenie - jak masz make to wypadało by mieć też jakieś minimal 
gnu - mkdir, touch, cat, cp...

Jak jednak nie masz aż takiej awersji do standardowych poleceń to możesz 
przerobić toto wg uznania - wprawdzie mi chodziło o optymalizację, ale 
-D też się pakuje w CFLAGS/CXXFLAGS więc na jedno wychodzi:
http://grota.be/~michoo/smieci/make_subdirs_opt

-- 
Pozdrawiam
Michoo

On 2013-03-22 17:39, Michoo wrote:
>> Nie. Szukam make-only rozwiązania.
> Głupie założenie - jak masz make to wypadało by mieć też jakieś minimal
> gnu - mkdir, touch, cat, cp...

Teraz wyobraź sobie że make-only da się odpalić na windowsie [*]. Nie 
jest mi to może jakoś bardzo niezbedne, ale dlaczego mam od razu 
spieprzyć używając pierdyliarda narzędzi poza make?

[*] dostarczane jest w prawie każdym cross-kompilatorze.

On 22.03.2013 17:45, Sebastian Biały wrote:
> On 2013-03-22 17:39, Michoo wrote:
>>> Nie. Szukam make-only rozwiązania.
>> Głupie założenie - jak masz make to wypadało by mieć też jakieś minimal
>> gnu - mkdir, touch, cat, cp...
>
> Teraz wyobraź sobie że make-only da się odpalić na windowsie [*]. Nie
> jest mi to może jakoś bardzo niezbedne, ale dlaczego mam od razu
> spieprzyć używając pierdyliarda narzędzi poza make?

Bo make służy do obsługi zależności przy budowaniu a nie do tworzenia 
plików, czy katalogów. Jak bardzo potrzebujesz, to zawsze możesz sobie 
zrobić plik platform, który zawiera:
CP=copy
RM=del
CAT=copy
i używać tego

Btw:
jak robisz "make clean"?


>
> [*] dostarczane jest w prawie każdym cross-kompilatorze.

I różne make często są niekompatybilne między sobą. Prościej jest 
wymagać gnu-make + min gnu niż "make, które obsługuje (....)".


-- 
Pozdrawiam
Michoo

On Fri, 22 Mar 2013 09:56:37 +0100,
Sebastian Biały <heby@poczta.onet.pl> wrote:
> On 2013-03-21 23:52, Marcin Konarski wrote:
>> To czego szukasz nazywa się "out of source(s) build".
>
> Używam tego od zawsze, ponieważ nienawidzę burdelu w źrodłach. Zawsze 
> targety znajdują się poza src.
>
>> $ make debug release ... ...
>
> Nie. make foo. I powstaje *kilka* foo z różnymi #define. Coś jak 
> boostbuild tylko ja mam. Nie chcę jawnie pokazywac targetów. To tak jak 
> gdyby w make było coś na kształt:
>
> for( param in FOO,BAR )
> {
> all:
>    ... -DPARAM=$param
> }

Szczerze mówiąc nie rozumiem Twojego problemu.
Skoro znasz tę technikę (out of sources build) to dlaczego jej tu nie
zastosujesz?

(make debug release to był tylko przykład BTW).

Nie wiem o ilu flagach mówisz, ale oczywiście każda zwiększa ilość
buildów "ilość wartości flagi" razy.

Niech F1=(arm|mips|x86), F2=(1000Hz|500Hz|100Hz), F3=(foo|bar)

Stosując tę samą koncepcję (OOSB) uzyskujesz np. strukturę:

build/
	arm/
		1000Hz/
			foo/
				debug/
					...
				release/
					...
			bar/
				debug/
					...
				release/
					...
		500Hz/
			foo/
				debug/
					...
				release/
					...
			bar/
				debug/
					...
				release/
					...
		100Hz/
			...
			...
	mips/
		...
		...
		...
		...
	x86/
		...
		...
		...
		...

Kolejność warstw w drzewie jest sprawą umowną.

W przypadku GNU make mogłoby to wyglądać jakoś tak.

#v+
F1=arm mips x86
F2=1000Hz 500Hz 100Hz
F3=foo bar

TARGETS=debug release

define OOSB
$(1)-$(2)-$(3)-$(4):
	mkdir -p build/$(1)/$(2)/$(3)/$(4) && \
	$(MAKE) -C build/$(1)/$(2)/$(3)/$(4) F1=$(1) F2=$(2) F3=$(3) $(4)
endef

INTERMED=$(foreach T,$(TARGETS),$(foreach IF1,$(F1),$(foreach IF2,$(F2),$(foreach IF3,$(F3),$(IF1)-$(IF2)-$(IF3)-$(T)))))

.PHONY: $(TARGETS) $(INTERMED)

all: $(TARGETS)

$(TARGETS): $(INTERMED)

$(foreach T,$(TARGETS),$(foreach IF1,$(F1),$(foreach IF2,$(F2),$(foreach IF3,$(F3),$(eval $(call OOSB,$(IF1),$(IF2),$(IF3),$(T)))))))

#v-

Trzeba jeszcze stworzyć Makefile do konkretnego buildu (też można go
zrobić generycznie), który będzie wrzucany do konkretnego katalogu,
najlepiej przy pomocy configure.ac (CMakekiem też
da radę).

Pozdrawiam.

-- 
  Huginn
GCS d? s: a C++$() UBLS++++$ P++ L++++$ E---
W+(-) N++ w-- O M- V- PS+ PE++ Y PGP-
t--- 5-- X- R !tv b++ DI+++ D+ G e* h r++ y**

On 2013-03-22 17:59, Michoo wrote:
> jak robisz "make clean"?

Jak zwykle czyli workaroundem. Make clean chyba jest niewykonalny 
inaczej, szczególnie jeśli ma zrobić clean na wielu projektach 
powiązanych zależnościami.

On 2013-03-22 18:17, Marcin Konarski wrote:
> Szczerze mówiąc nie rozumiem Twojego problemu.
> Skoro znasz tę technikę (out of sources build) to dlaczego jej tu nie
> zastosujesz?

Ponieważ docelowo chcę miec:

make foo

i znaleźc w katalogu bin N targetów foo przebudowanych dla różnych 
#define. OOSB nic tu nie zmienia.

> Niech F1=(arm|mips|x86), F2=(1000Hz|500Hz|100Hz), F3=(foo|bar)
> Stosując tę samą koncepcję (OOSB) uzyskujesz np. strukturę:
>
> build/
> 	arm/
> 		1000Hz/

Wiem. Gorzej, już tak mam. Tyle że zewnętrzna pętla po parametrach 
robiona jest przez basha. Kilka razy to uprosciło budowę make, ale jest 
nie w/g sztuki i wiąże mnie z *shem. Pozornie to nie są wady, ale tylko 
pozornie...

> define OOSB
> $(1)-$(2)-$(3)-$(4):
> 	mkdir -p build/$(1)/$(2)/$(3)/$(4)&&  \
> 	$(MAKE) -C build/$(1)/$(2)/$(3)/$(4) F1=$(1) F2=$(2) F3=$(3) $(4)
> endef


No wlaśnie :/ miałem nadzieję że to jakoś da się w make bez takiego 
rekodzieła zrobić.

On 22.03.2013 18:36, Sebastian Biały wrote:
>
> Wiem. Gorzej, już tak mam. Tyle że zewnętrzna pętla po parametrach
> robiona jest przez basha. Kilka razy to uprosciło budowę make, ale jest
> nie w/g sztuki i wiąże mnie z *shem. Pozornie to nie są wady, ale tylko
> pozornie...

To akurat nie jest pozorna wada tylko realna - nie działa za dobrze z -jN

-- 
Pozdrawiam
Michoo

On Fri, 22 Mar 2013 01:47:16 +0000 (UTC),
Edek Pienkowski <edek.pienkowski@gmail.com> wrote:
> Dnia Thu, 21 Mar 2013 22:52:04 +0000, Marcin Konarski wyszeptal:
>
>> To czego szukasz nazywa się "out of source(s) build".
>> Technicznie jest to dość skomplikowane i eleganckie rozwiązanie
>> to zestaw makefile'i (najlepiej z configure.ac) na kila tysięcy linii.
>> CMake również umożliwia "out of sources build".
>
> Technicznie to nie jest strudne i nie wymaga tysięcy linii, ale 
> zapytałbym najpierw na ile znasz make.

[amok@vegeta](0/0)~/src/yaal/$ cat _aux/mk/* ./configure.ac ./Makefile.mk.in | wc -l
1255

Faktycznie przesadziłem z estymacją "tylko" 1200 linii.

>
> Zacząłbym czytanie manuala od elementów w make, które generują
> framenty Makefile w samym Makefile (w locie, takie "makra" 
> powiedzmy.
>
> Wtedy całą kompilację wrzuca się w takie "makra", pojawiają
> się wtedy $$ i inne nieczytelne rzeczy, z góry mówię
> że to nie wygląda dobrze, ale potem takie makro
> wykonuje się w pętli (for ...) dla parametrów i efekt jest taki,
> jakbyś dla każdej kombinacji parametrów miał osobny fragment
> Makefile po inteligentym c-c c-v, co za piszącego robi
> sam make. Z tego powstaje jeden Makefile, z targetami, 
> zależnościami itd., oczywiście nie jako plik tylko
> podczas budowania.
>
> Mówię o nieczęsto używanym feature, i debugowanie generowanych
> targetów wymaga kilku sztuczek, ale właśnie w takim celu
> powstała ta część make.

Ten fragment to chyba nie do mnie.
GNU make mam w małym palcu, i podtrzymuję swoją opinię,
OOSB jest nietrywialny do poprawnego i eleganckiego
zaimplementowania.

-- 
  Huginn
GCS d? s: a C++$() UBLS++++$ P++ L++++$ E---
W+(-) N++ w-- O M- V- PS+ PE++ Y PGP-
t--- 5-- X- R !tv b++ DI+++ D+ G e* h r++ y**

Dnia Fri, 22 Mar 2013 18:36:01 +0100, Sebastian Biały wyszeptal:

> No wlaśnie :/ miałem nadzieję że to jakoś da się w make bez takiego 
> rekodzieła zrobić.

Czy ja Ci aby nie odpowiedziałem na pytanie "jak"?

-- 
Edek

Dnia Fri, 22 Mar 2013 19:14:13 +0000, Marcin Konarski wyszeptal:

> Ten fragment to chyba nie do mnie.
> GNU make mam w małym palcu, i podtrzymuję swoją opinię,
> OOSB jest nietrywialny do poprawnego i eleganckiego
> zaimplementowania.

No nie było do Ciebie, chociaż na Twój post odpowiadałem.

Robi się albo out of source albo nie out of source (za pomocą
suffixów nazw), wygodniej jest out of source, dlatego kontynuowałem
Twoją wypowiedź. Było do OPa.

-- 
Edek

On 2013-03-23 01:06, Edek Pienkowski wrote:
>> No wlaśnie :/ miałem nadzieję że to jakoś da się w make bez takiego
>> rekodzieła zrobić.
> Czy ja Ci aby nie odpowiedziałem na pytanie "jak"?

Jak wiem jak *można*. Problem w tym że jak człowiek patrzy na takie 
workaroundy przypominające najgorsze wypociny programatorów perla to 
sobie myśli: przeciez to nie jest mozliwe zeby się nie dało inaczej. 
Szukam tego "inaczej" ale niestety jesli dobrze widzę to mam dwa 
wyjścia: zrobić perl-like sieczkę w make albo wyprowadzić część logiki 
do basha. Trudno, coś wybiorę :/