Minęło trochę czasu. odkąd ostatnio pisałem/modyfikowałem na własne
potrzeby Makefile. W bardzo małych projektach zwykle podawałem po prostu
nazwy plików, przy większych stosowałem wzór pożyczony z jakiegoś
internetowego tutorialu. jego główna część wyglądała następująco:

.PHONY: all clean



all: $(TARGET).hex





$(HEXDIR)/%.hex: $(OBJDIR)/%.ihx

$(S) packihx $^ > $@



$(OBJDIR)/%.ihx: $(OBJ)

$(S) $(CC) -o $@ $(LFLAGS) $^



$(OBJDIR)/%.c.rel: $(SRCDIR)/%.c

$(S) $(CC) -o $@ $(CFLAGS) -c $^



$(OBJDIR)/%.asm.rel: $(SRCDIR)/%.asm

$(S) $(AS) $(AFLAGS) -o $@ $^



clean:

$(S) rm -rf $(OBJDIR)/*

$(S) rm -rf $(TARGET).hex

Z powodzeniem wykorzystywałem go z 8051 (SDCC) oraz podczas pisania
mniejszych projektów pod AVR-y, szczególnie gdy na danym komputerze nie
miałem akurat zainstalowanego Atmel Studio.

Teraz próbuję go przerobić na potrzeby pewnego projektu dla 6502
(kompilator CC65). Sam projekt się kompiluje, jeśli wpisać polecenia
ręcznie albo podam je sekwencyjnie, plik po pliku w Makefile. Próba
zautomatyzowania go jak powyżej się nie udaje. Wydaje mi się, że wynika
to z tego, że projekt składa się zarówno z plików *.c jak i
asemblerowego kodu w plikach *.s.

Co chcę uzyskać?

1) w katalogu projektu mam podkatalogi src, inc, obj, lib oraz hex.
Pierwszy zawiera pliki źródłowe (zarówno *.c, jak i *.s), drugi pliki
nagłówkowe *.h, do trzeciego trafiają skompilowane ploki obiektowe *.o,
a w trzecim trzymam przygotowaną wcześniej bibliotekę oraz plik cfg,
wykorzystywane przez linker.
2) W pierwszej fazie kompilator cc65 bierze wszystkie pliki *.c i
generuje na ich podstawie pliki asemblerowe *.s (z tego co wiem CC65 nie
potrafi od razu wygenerować pliku binarnego z kodu C).
3) Następnie asembler ca65 na podstawie każdego pliku *.s (zarówno tego
wygenerowanego przez cc65, jak i znajdującego się tam od początku)
generuje plik *.o, umieszczając go w folderze obj.
4) Linker ld64 łączy wszystkie pliki *.o z tego folderu w jeden plik
binarny.
5) Na końcu plik binarny jest konwertowany do formatu *.hex, ale to
akurat najmniejszy problem.

Ktoś mi powie jak to powinno wyglądać?

do góry

W dniu poniedziałek, 20 sierpnia 2018 10:09:44 UTC-5 użytkownik Atlantis napisał:
> Minęło trochę czasu. odkąd ostatnio pisałem/modyfikowałem na własne
> potrzeby Makefile. W bardzo małych projektach zwykle podawałem po prostu
> nazwy plików, przy większych stosowałem wzór pożyczony z jakiegoś
> internetowego tutorialu. jego główna część wyglądała następująco:
>

>
> Ktoś mi powie jak to powinno wyglądać?

O ile dobrze pamietam (czyli wiele ci pewnie nie pomoge :) ) to dla kazdego katalogu
trzeba albo stworzyc makefile albo utworzyc regulke w tym glownym.

Makefile dziala na zasadzie skladnik -> produkt.
W regulkach podajesz zaleznosci. Czyli powyzej hex zalezy od ihx, ihx od obj itd.
Dla kazdej klasy obiektow podajesz przepis jak go uzyskac.
Czyli dla np. obj to cc -o

Tam cala filozofia lezy tylko w poukladaniu plikow i zastosowaniu odpowiednich
zmiennych oraz ewentualnym podzieleniu projektu na odpowiednie moduly w przypadku
kiedy makefile robi sie skomplikowany.

Make sledzi co sie od kiedy zmienilo i odswieza tylko te elementy ktore wymagaja
ponownego przetworzenia.

To samo w praktyce mozesz uzyskac piszac "slepy" skrypt ktory ci zrekompiluje i
zlinkuje calosc za kazdym razem. Tak chyba ostatnio dziala cala otoczka javova w
nowoczesnych IDE. Co mnie nieco irytuje.

Niestety makefile robilem tak dano ze nie podejme sie napisania ci szkieletu dla tego
co podales. Moze ktos inny jest bardziej biegly.
Ale jak zerkniesz w tutki make to mysle ze w 20 minut sklecisz co ci trzeba.

do góry

On Mon, 20 Aug 2018 17:09:17 +0200, Atlantis <m...@w...pl>
wrote:
> 1) w katalogu projektu mam podkatalogi src, inc, obj, lib oraz hex.

A nie lepiej projekt podzielić na podkatalogi z własnymi Makefile i
jeden główny katalog który wpierw "przeleci" zależne podkatalogi z
Makefile"ami a potem zlinkuje wszystko razem?

--
Marek

do góry

Atlantis <m...@w...pl> wrote:

> 2) W pierwszej fazie kompilator cc65 bierze wszystkie pliki *.c i
> generuje na ich podstawie pliki asemblerowe *.s (z tego co wiem CC65 nie
> potrafi od razu wygenerować pliku binarnego z kodu C).
> 3) Następnie asembler ca65 na podstawie każdego pliku *.s (zarówno tego
> wygenerowanego przez cc65, jak i znajdującego się tam od początku)
> generuje plik *.o, umieszczając go w folderze obj.

Jeśli chcesz dostosować to do istniejącego makefile to może najprościej
będzie ci zrobić wrapper, który wywoła cc65, a potem ca65 i skasuje plik
.s?

> 4) Linker ld64 łączy wszystkie pliki *.o z tego folderu w jeden plik
> binarny.
> 5) Na końcu plik binarny jest konwertowany do formatu *.hex, ale to
> akurat najmniejszy problem.
>
> Ktoś mi powie jak to powinno wyglądać?

Jeśli upierasz się przy GNU Make, to zrobiłym to tak (nie znam składni
cc65 i innych narzędzi, dostosuj w razie czego, ścieżki też):

NAME = maketest
SRCS = maketest.c maketest2.c

ASMS = $(SRCS:.c=.s)
OBJS = $(ASMS:.s=.o)

.PHONY: all clean
all: $(NAME).hex

%.s:
cc65 -o $@ $<

%.o:
ca65 -o $@ $<

$(ASMS): $(SRCS)

$(OBJS): $(ASMS)

$(NAME).bin: $(OBJS)
ld64 -o $(NAME).bin $(OBJS)

$(NAME).hex: $(NAME).bin
program_do_konwersji_do_hex $(NAME).hex $(NAME).bin

clean:
rm -f $(NAME).hex $(NAME).bin $(OBJS) $(ASMS)

Prosty test pokazuje, że działa (tylko PATH ustawiłem na .:$PATH żeby
wykryło te skrypty udające cc65 itd.):

$ ls -l
razem 16
lrwxrwxrwx 1 queequeg queequeg 4 sie 22 12:55 ca65 -> cc65
-rwxr-xr-x 1 queequeg queequeg 9 sie 22 12:56 cc65
lrwxrwxrwx 1 queequeg queequeg 4 sie 22 12:55 ld64 -> cc65
-rw-r--r-- 1 queequeg queequeg 404 sie 22 12:56 Makefile
-rw-r--r-- 1 queequeg queequeg 5 sie 22 12:45 maketest1.c
-rw-r--r-- 1 queequeg queequeg 5 sie 22 12:51 maketest2.c
lrwxrwxrwx 1 queequeg queequeg 4 sie 22 12:55 program_do_konwersji_do_hex -> cc65

$ cat cc65
cp $3 $2

$ make
cc65 -o maketest1.s maketest1.c
cc65 -o maketest2.s maketest1.c
ca65 -o maketest1.o maketest1.s
ca65 -o maketest2.o maketest1.s
ld64 -o maketest.bin maketest1.o maketest2.o
program_do_konwersji_do_hex -o maketest.hex maketest.bin

$ ls -l
razem 40
lrwxrwxrwx 1 queequeg queequeg 4 sie 22 12:55 ca65 -> cc65
-rwxr-xr-x 1 queequeg queequeg 9 sie 22 12:56 cc65
lrwxrwxrwx 1 queequeg queequeg 4 sie 22 12:55 ld64 -> cc65
-rw-r--r-- 1 queequeg queequeg 404 sie 22 12:56 Makefile
-rw-r--r-- 1 queequeg queequeg 5 sie 22 12:45 maketest1.c
-rw-r--r-- 1 queequeg queequeg 5 sie 22 12:57 maketest1.o
-rw-r--r-- 1 queequeg queequeg 5 sie 22 12:57 maketest1.s
-rw-r--r-- 1 queequeg queequeg 5 sie 22 12:51 maketest2.c
-rw-r--r-- 1 queequeg queequeg 5 sie 22 12:57 maketest2.o
-rw-r--r-- 1 queequeg queequeg 5 sie 22 12:57 maketest2.s
-rw-r--r-- 1 queequeg queequeg 5 sie 22 12:57 maketest.bin
-rw-r--r-- 1 queequeg queequeg 5 sie 22 12:57 maketest.hex
lrwxrwxrwx 1 queequeg queequeg 4 sie 22 12:55 program_do_konwersji_do_hex -> cc65

$ make clean
rm -f maketest.hex maketest.bin maketest1.o maketest2.o maketest1.s maketest2.s

$ ls -l
razem 16
lrwxrwxrwx 1 queequeg queequeg 4 sie 22 12:55 ca65 -> cc65
-rwxr-xr-x 1 queequeg queequeg 9 sie 22 12:56 cc65
lrwxrwxrwx 1 queequeg queequeg 4 sie 22 12:55 ld64 -> cc65
-rw-r--r-- 1 queequeg queequeg 404 sie 22 12:56 Makefile
-rw-r--r-- 1 queequeg queequeg 5 sie 22 12:45 maketest1.c
-rw-r--r-- 1 queequeg queequeg 5 sie 22 12:51 maketest2.c
lrwxrwxrwx 1 queequeg queequeg 4 sie 22 12:55 program_do_konwersji_do_hex -> cc65

--
https://www.youtube.com/watch?v=9lSzL1DqQn0

do góry

Queequeg <q...@t...no1> wrote:

> SRCS = maketest.c maketest2.c

maketest1.c tu miało być a nie maketest.c (tzn. z taką składnią
testowałem), to żebyś się nie dziwił że w poleceniach później jest
maketest1.c a nie maketest.c :)

--
https://www.youtube.com/watch?v=9lSzL1DqQn0

do góry

Queequeg <q...@t...no1> wrote:

Jeszcze wyjaśnienie, co to robi.

> NAME = maketest

Ustawia nazwę projektu (pliku .bin i .hex), jest używana niżej.

> SRCS = maketest.c maketest2.c

Lista plików źródłowych.

> ASMS = $(SRCS:.c=.s)

Lista plików .s stworzona z listy plików źródłowych zamieniając .c na .s.

> OBJS = $(ASMS:.s=.o)

Lista plików .o stworzona jak wyżej (z listy plików .s, zamieniając .s na
.o).

> .PHONY: all clean

Nawet jak będzie istniał plik all i clean, to i tak wykona te targety.

> all: $(NAME).hex

Określa, że make all będzie miało taki sam efekt, jak make maketest.hex
(make tworzy plik, all to target a nie plik).

> %.s:
> cc65 -o $@ $<

Określa regułę dla utworzenia pliku .s. $@ to plik wyjściowy (.s), $<
wejściowy (.c).

> %.o:
> ca65 -o $@ $<

Analogicznie.

> $(ASMS): $(SRCS)

Tworzy zależność plików .s od plików .c.

> $(OBJS): $(ASMS)

Analogicznie .o od .s.

> $(NAME).bin: $(OBJS)
> ld64 -o $(NAME).bin $(OBJS)

Tworzy zależność pliku .bin od plików .o i tworzy regułę utworzenia tego
pliku z plików .o (z listy OBJS).

> $(NAME).hex: $(NAME).bin
> program_do_konwersji_do_hex $(NAME).hex $(NAME).bin

Tworzy zależność pliku .hex od pliku .bin i tworzy regułę, jak wyżej. W
testach też dodałem -o przed $(NAME).hex.

> clean:
> rm -f $(NAME).hex $(NAME).bin $(OBJS) $(ASMS)

Tworzy target kasujący pliki potworzone przez makefile, żeby make clean je
usunęło. Kasuje plik maketest.hex, maketest.bin, pliki .o i pliki .s.

--
https://www.youtube.com/watch?v=9lSzL1DqQn0

do góry