Elektroda.pl
Elektroda.pl
X
Elektroda.pl
Advanced Search
Elektroda.pl
Please add exception to AdBlock for elektroda.pl.
If you watch the ads, you support portal and users.

[GCC-Makefile/ECLIPSE] - Ścieżka względna w pliku makefile

Dexu 08 Feb 2013 11:35 4074 16
Computer Controls
Reply | New topic
  • #1
    Dexu
    Level 13  
    Witam

    Dla własnej wygody i dla możliwości przekazywania mojego Eclipse na dowolny komputer bez konieczności żmudnej konfiguracji, postanowiłem zrobić je jak najbardziej "portable".
    Musiałem więc zmienić wszystkie ścieżki na względne (najczęściej do ../workspace).
    Udało mi się skonfigurować Eclipse tak, że Toolchain (Sourcery G++ Lite Edition for ARM) nie sprawia już żadnych problemów.
    Do testów użyłem prosty projekt zrobiony przez Freediego Chopina, który wykorzystuje ręcznie konfigurowany plik Makefile.
    I tu pojawia się jedyne miejsce, gdzie muszę podać ścieżkę bezwzględną w celu namierzenia Toolchaina:

    Code: Expand Select all Copy to clipboard 
    TOOLCHAIN = G:\_DexxIDE\workspace\arm-2012.09\bin\arm-none-eabi-


    Próbowałem używać zmiennych środowiskowych istniejących w moim projekcie np:
    $(workspace_loc)
    niestety nie działają one w Makefile.

    Czy istnieje jakaś możliwość podania w tym miejscu ścieżki względnej ?
    Dodam tylko że mój toolchain jest poziom niżej niż sam projekt czyli:
    ..\workspace\projekt
    ..\workspace\arm-2012.09 <= Toolchain
  • Computer Controls
  • #2
    mickpr
    Level 39  
    Zacznij od miejsca w którym wykonywany jest program make, a potem zgrabnie '..' i '\' dojdziesz do właściwego katalogu.
  • Helpful post
    #3
    Freddie Chopin
    MCUs specialist  
    Szczerze mówiąc to w moich projektach nie mam ani jednej ścieżki absolutnej, więc generalnie nie wiem w ogóle skąd wynika ten problem...

    Co do samego toolchaina, to nie lepiej po prostu ustawić go sobie w systemowym PATH i wywoływać bez żadnej ścieżki?

    mickpr wrote:
    '\'

    Ja bym się kilka razy zastanowił zanim wstawię backslasha do Makefile'a (;

    4\/3!!
  • Helpful post
    #4
    mickpr
    Level 39  
    Freddie Chopin wrote:
    Co do samego toolchaina, to nie lepiej po prostu ustawić go sobie w systemowym PATH i wywoływać bez żadnej ścieżki?
    Nie jest to dobre rozwiązanie, jak masz wiele toolchain-ów.
    Freddie Chopin wrote:
    Ja bym się kilka razy zastanowił zanim wstawię backslasha do Makefile'a (;
    Pomyliłem się... Masz rację. Backslash to znak kontynuacji obecnego wiersza w następnym. Należy użyć "slash".
    Wszystko to wina Microsoftu. To on namieszał w tym temacie..
  • #5
    Dexu
    Level 13  
    Freddie Chopin wrote:

    Co do samego toolchaina, to nie lepiej po prostu ustawić go sobie w systemowym PATH i wywoływać bez żadnej ścieżki?


    No tak ale grzebanie w Systemowym PATH nie idzie w parze z portable i własnie tego starałem się pozbyć z Twojej konfiguracji.

    mickpr wrote:

    Zacznij od miejsca w którym wykonywany jest program make, a potem zgrabnie '..' i '\' dojdziesz do właściwego katalogu.


    Testowałem już wcześniej konfigurację ze slashem i wysypywała się po pewnym czasie:
    Code: Expand Select all Copy to clipboard 
    12:12:26 **** Incremental Build of configuration Default for project stm32_blink_led ****
cs-make all 
'Assembling file: startup.S'
../arm-2012.09/bin/arm-none-eabi-gcc -x assembler-with-cpp -c -mcpu=cortex-m3 -mthumb -g -ggdb3 -Wa,-amhls=out/startup.lst  -MD -MP -MF out/startup.d -I.  startup.S -o out/startup.o
' '
'Compiling file: gpio.c'
../arm-2012.09/bin/arm-none-eabi-gcc -c -mcpu=cortex-m3 -mthumb -O0 -ffunction-sections -fdata-sections -Wall -Wstrict-prototypes -Wextra -std=gnu89 -g -ggdb3 -fverbose-asm -Wa,-ahlms=out/gpio.lst -DSTM32F10X_MD -MD -MP -MF out/gpio.d -I.  gpio.c -o out/gpio.o
' '
'Compiling file: main.c'
../arm-2012.09/bin/arm-none-eabi-gcc -c -mcpu=cortex-m3 -mthumb -O0 -ffunction-sections -fdata-sections -Wall -Wstrict-prototypes -Wextra -std=gnu89 -g -ggdb3 -fverbose-asm -Wa,-ahlms=out/main.lst -DSTM32F10X_MD -MD -MP -MF out/main.d -I.  main.c -o out/main.o
' '
'Compiling file: vectors.c'
../arm-2012.09/bin/arm-none-eabi-gcc -c -mcpu=cortex-m3 -mthumb -O0 -ffunction-sections -fdata-sections -Wall -Wstrict-prototypes -Wextra -std=gnu89 -g -ggdb3 -fverbose-asm -Wa,-ahlms=out/vectors.lst -DSTM32F10X_MD -MD -MP -MF out/vectors.d -I.  vectors.c -o out/vectors.o
' '
'Linking target: out/stm32_blink_led.elf'
../arm-2012.09/bin/arm-none-eabi-g++ -mcpu=cortex-m3 -mthumb -TSTM32F103xB_rom.ld -g -Wl,-Map=out/stm32_blink_led.map,--cref,--no-warn-mismatch -Wl,--gc-sections -nostartfiles  out/startup.o out/gpio.o out/main.o out/vectors.o    -o out/stm32_blink_led.elf
' '
'Creating extended listing: out/stm32_blink_led.lss'
../arm-2012.09/bin/arm-none-eabi-objdump -S out/stm32_blink_led.elf > out/stm32_blink_led.lss
Der Befehl ".." ist entweder falsch geschrieben oder
konnte nicht gefunden werden.
cs-make: *** [out/stm32_blink_led.lss] Error 1


    Teraz przetestowałem wersję z backslashem i o dziwo działa bez problemów.

    Dziękuję za pomoc, teraz w końcu jedyne co trzeba zrobić na innym komputerze, żeby otworzyć i kompilować projekt, to poprawnie wybrać workspace :)
  • Computer Controls
  • #6
    Freddie Chopin
    MCUs specialist  
    Dexu wrote:
    No tak ale grzebanie w Systemowym PATH nie idzie w parze z portable i własnie tego starałem się pozbyć z Twojej konfiguracji.

    Niby tak, ale są pewne granice tej przenośności. Dla przykładu Twój komputer musi mieć make.exe + jeszcze kilka programów z Coreutils (których zresztą nie masz wszystkich i to jest powód dla którego nie działa ze slashem "w przód" - u mnie działa (; ) w systemowym PATH, więc tak czy siak jesteś uzależniony od tego co jest w systemie...

    P.S. backslash na Linuxie raczej nie będzie dobrze widziany, więc tutaj też nie ma specjalnej przenośności, a tak czy siak byś jej nie miał, bo dla Linuxa potrzebny jest inny kompilator.

    mickpr wrote:
    Nie jest to dobre rozwiązanie, jak masz wiele toolchain-ów.

    Muszę tutaj powiedzieć, że jak ktoś ma wiele toolchainów i jeszcze chce WIELU używać, to ma wiele problemów... Ja mam osobiście z 5 różnych, ale używam tylko jednego - do wszystkich projektów. Czasami jak mam nastrój na porównania, to modyfikując katalogi sobie ten "najnowszy" po prostu "wyłączam" i używam innych.

    No i czy trzymanie 400MB toolchaina w katalogu z projektami jest optymalne (;

    4\/3!!
  • #7
    mickpr
    Level 39  
    Freddie Chopin wrote:
    Muszę tutaj powiedzieć, że jak ktoś ma wiele toolchainów i jeszcze chce WIELU używać, to ma wiele problemów...
    Ja mam... Używam z reguły ARM więc Code Sourcery, ale mam też:
    - toochain do CX2450x (ARM1176) - czasem grzebię w tunerze SAT :)
    - toochain do PIC18 (z MPLABX) - to też do tunera,
    - toolchain do AVR - wiadomo do czego..
    - Mingw GCC - jak przyjdzie mi napisać jakiś example w C.

    I nie mam żadnych kłopotów. Wszystko skonfigurowane indywidualnie pod konkretne IDE (przeważa Eclipse).
    Wg mnie sposób zdefiniowania ścieżki PATH w Windows jest paskudny.
    Szczególnie jak tysiące głupich programów nie wiadomo czemu chce mieć tam swój "wkład".
  • #8
    Freddie Chopin
    MCUs specialist  
    Jest jeden drobny problem w Twojej odpowiedzi, którego nie zauważyłeś - żaden z wymienionych przez ciebie toolchainów (poza Code Sourcery), nie ma plików których nazwy zaczynają się od "arm-none-eabi-", nieprawdaż? (; Tak więc - dla celów tej dyskusji - masz JEDNEGO toolchaina (dla bare-metal ARM). Do tego wszystkie cztery które wymieniłeś również mają unikatowe prefixy (no może z wyjątkiem mingw).

    4\/3!!
  • #9
    Dexu
    Level 13  
    Freddie Chopin wrote:
    Niby tak, ale są pewne granice tej przenośności. Dla przykładu Twój komputer musi mieć make.exe + jeszcze kilka programów z Coreutils (których zresztą nie masz wszystkich i to jest powód dla którego nie działa ze slashem "w przód" - u mnie działa (; ) w systemowym PATH, więc tak czy siak jesteś uzależniony od tego co jest w systemie...


    No właśnie że nie, jedyne co mój komputer potrzebuje to zainstalowaną wirtulna maszynę javy, a resztę załatwia eclipse "rozszerzając" sobie systemowe PATH (na szybko opisałem wszystko tu link )
    Dla przykłądu na komputerze testowym PATH wygląda tak:

    Code: Expand Select all Copy to clipboard 
    C:/Program Files (x86)/Java/jre7/bin/client;C:/Program Files (x86)/Java/jre7/bin;C:/Program Files (x86)/Java/jre7/lib/i386;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;

    a Eclipse kompiluje projekt bez problemu.

    Freddie Chopin wrote:
    No i czy trzymanie 400MB toolchaina w katalogu z projektami jest optymalne (;

    Toolchain jest jeden na workspace, nie jest to może super optymalne ale zawsze jest coś za coś.

    Freddie Chopin wrote:
    Jest jeden drobny problem w Twojej odpowiedzi, którego nie zauważyłeś - żaden z wymienionych przez ciebie toolchainów (poza Code Sourcery), nie ma plików których nazwy zaczynają się od "arm-none-eabi-", nieprawdaż? (; Tak więc - dla celów tej dyskusji - masz JEDNEGO toolchaina (dla bare-metal ARM). Do tego wszystkie cztery które wymieniłeś również mają unikatowe prefixy (no może z wyjątkiem mingw).

    4\/3!!


    Tak jak piszesz, np. plik arm-none-eabi-gcc.exe nie robi nic tylko otwiera odpowiednio "schowany" gcc.exe, do którego ścieżka musi być dodana do PATH. Jest to zabezpieczenie umożliwiające korzystanie z wielu toolchainów.
    Dlatego ja musiałem podmienić plik arm-none-eabi-gcc.exe na gcc.exe i zmienić mu nazwę znów na arm-none-eabi-gcc.exe.
  • #10
    Freddie Chopin
    MCUs specialist  
    Dexu wrote:
    No właśnie że nie, jedyne co mój komputer potrzebuje to zainstalowaną wirtulna maszynę javy, a resztę załatwia eclipse "rozszerzając" sobie systemowe PATH (na szybko opisałem wszystko tu link )

    Skoro rozszerza o folder w którym jest make.exe, to równie dobrze może rozszerzać o folder z kompilatorem...

    Dexu wrote:
    Tak jak piszesz, np. plik arm-none-eabi-gcc.exe nie robi nic tylko otwiera odpowiednio "schowany" gcc.exe, do którego ścieżka musi być dodana do PATH. Jest to zabezpieczenie umożliwiające korzystanie z wielu toolchainów.
    Dlatego ja musiałem podmienić plik arm-none-eabi-gcc.exe na gcc.exe i zmienić mu nazwę znów na arm-none-eabi-gcc.exe.

    Eeee... no niezbyt... arm-none-eabi-gcc.exe w istocie jest tylko wrapperem dla innego pliku (gcc.exe), ale tenże "inny" plik nie musi być dodanych do PATH. Innymi słowy - w PATH powinien być tylko arm-none-eabi-gcc.exe, a nie gcc.exe (nie mówimy tu o natywnym kompilatorze czy mingw).

    arm-none-eabi-gcc otwiera plik gcc poprzez względną ścieżkę, a nie poprzez PATH.

    Apropo Twojego poradnika:

    Quote:
    Okazało się że trzeba najpierw ręcznie w katalogu projektu utworzyć folder ..\out

    Właśnie nie trzeba, tylko trzeba mieć zainstalowane coreutils - pisałem o tym. Widać że ich nie masz, bo do stdout trafia za dużo apostrofów.

    Quote:
    okazało sie ze pliki ..\workspace\arm-2012.09\bin\arm-none-eabi-gcc nie działają bez poprawnie ustawionej systemowej ścieżki PATH.

    Oczywiście że działają... Sprawdziłem osobiście - gdy w PATH nie ma żadnego arm-none-eabi-gcc i (to ważne!) żadnego gcc, mogę sobie kompilować projekt korzystając z pełnej ścieżki do kompilatora. Ale tylko ze slashami do przodu.

    Code: Expand Select all Copy to clipboard 
    ...
Compiling file: FreeRTOS/list.c
d:/Elektronika/ARM/bleeding-edge-toolchain/releases/gcc-arm-none-eabi-4_7-130207
/bin/arm-none-eabi-gcc -c -mcpu=cortex-m3 -mthumb -Os -ffunction-sections -fdata
-sections -Wall -Wstrict-prototypes -Wextra -std=gnu89 -g -ggdb3 -fverbose-asm -
Wa,-ahlms=out/list.lst  -DSTM32L1XX_MD  -MD -MP -MF out/list.d -I.  -Iinc  -IFre
eRTOS/include  -IFreeRTOS/portable/GCC/ARM_CM3  -IFatFS FreeRTOS/list.c -o out/l
ist.o
...
Linking target: out/projekt.elf
d:/Elektronika/ARM/bleeding-edge-toolchain/releases/gcc-arm-none-eabi-4_7-130207
/bin/arm-none-eabi-g++ -mcpu=cortex-m3 -mthumb -TSTM32L15xxB_rom.ld -g -Wl,-Map=
out/projekt.map,--cref,--no-warn-mismatch -Wl,--gc-sect
ions  out/startup_ARMv7-M_E_.o out/printf-stdarg.o out/syscalls.o out/vectors_ST
M32L1xx_md.o out/croutine.o out/list.o out/queue.o out/tasks.o out/timers.o out/
port.o out/heap_3.o out/ff.o out/syscall.o out/command.o out/gpio.o out/helper.o
 out/i2c.o out/main.o out/overrides.o out/rcc.o out/spi.o out/usart.o out/mmc.o
 -o out/projekt.elf
...
Size of target .elf file:
d:/Elektronika/ARM/bleeding-edge-toolchain/releases/gcc-arm-none-eabi-4_7-130207
/bin/arm-none-eabi-size -B out/projekt.elf
   text    data     bss     dec     hex filename
  17028    1308    3732   22068    5634 out/projekt.elf



d:\Elektronika\ARM\projects\projekt>arm-none-eabi-gcc
Nazwa 'arm-none-eabi-gcc' nie jest rozpoznawana jako polecenie wewnętrzne lub ze
wnętrzne,
program wykonywalny lub plik wsadowy.

d:\Elektronika\ARM\projects\projekt>gcc
Nazwa 'gcc' nie jest rozpoznawana jako polecenie wewnętrzne lub zewnętrzne,
program wykonywalny lub plik wsadowy.


    4\/3!!
  • #11
    Dexu
    Level 13  
    Freddie Chopin wrote:
    Eeee... no niezbyt... arm-none-eabi-gcc.exe w istocie jest tylko wrapperem dla innego pliku (gcc.exe), ale tenże "inny" plik nie musi być dodanych do PATH. Innymi słowy - w PATH powinien być tylko arm-none-eabi-gcc.exe, a nie gcc.exe (nie mówimy tu o natywnym kompilatorze czy mingw).

    arm-none-eabi-gcc otwiera plik gcc poprzez względną ścieżkę, a nie poprzez PATH.


    No to w takim razie nie wiem, dlaczego bez normalnej instalacji wywołanie arm-none-eabi-gcc.exe kończy się błędem. Wg mnie względna ścieżka powinna zadziałać nawet z Sourcery CodeBench Lite wypakowanej z pobranego archiwum IA32 Windows TAR.

    Freddie Chopin wrote:
    Cytat:
    Okazało się że trzeba najpierw ręcznie w katalogu projektu utworzyć folder ..\out

    Właśnie nie trzeba, tylko trzeba mieć zainstalowane coreutils - pisałem o tym. Widać że ich nie masz, bo do stdout trafia za dużo apostrofów.


    Na pewno nie mam bo próbuje to konfigurować na czystej instalacji Windowsa. Myślisz, że można przenieść coreutils też do folderu workspace i pozwolić eclipse na doklejanie go do PATH (wydaje mi się, że w takim wypadku kompilator nie będzie go widział).
  • #13
    Dexu
    Level 13  
    Błąd, który mi się pojawia to:

    Code: Expand Select all Copy to clipboard 
    
C:\arm-2012.09\bin\arm-none-eabi-gcc.exe nie jest prawidłową aplikacją systemu Win32


    A samo dopisanie czegokolwiek do systemowej PATH nie wchodzi w grę, bo ma to działać na systemach gdzie dostęp do nich jest zablokowany przez administratora (tak samo jak instalowanie czegokolwiek)
  • #14
    Freddie Chopin
    MCUs specialist  
    No ale - powtarzam - przecież modyfikujesz PATH, za pomocą Eclipse - czemu po prostu nie dopisać do tego PATH ścieżki z kompilatorem? To MUSI działać w ten sposób (i działa, bo kiedyś sprawdzałem). No i dorzuć sobie do tego folderu Coreutils, one są naprawdę potrzebne (i nie chodzi o samo make.exe).

    4\/3!!
  • #15
    Dexu
    Level 13  
    Wydaje mi się, że ta zmodyfikowana zmienna środowiskowa jest widoczna tylko z poziomu eclipse, a toolchain już tego nie widzi (dlatego musiałem dopisać dodatkowo w pliku makefile ścieżkę do toolchania).
    Dodałem też Coreutils do PATH w eclipse, ale też nie pomogło i slashe dalej nie działają tak jak i tworzenie katalogu out.
  • #16
    Freddie Chopin
    MCUs specialist  
    Hmm... Wydaje mi się, że takie zmodyfikowane PATH "przekazywane" jest do kompilatora... Muszę to sprawdzić, ale jestem prawie pewny że to działa, bo kiedyś tak miałem jakiś projekt skonfigurowany i działało jak należy...

    No ale sprawdzę.

    Co do pozostałych problemów, to na początek próbowałbym walczyć ustawiając systemowe PATH, a dopiero potem można próbować ustawianie tegoż PATHa przenieść do Eclipse - jak już wszystko zadziała jak trzeba.

    EDIT: Sprawdziłem i w istocie u mnie działa. W systemowym PATH nie można odnaleźć plików takich jak arm-none-eabi-gcc czy gcc. Jeśli dopiszę folder w którym jest toolchain do PATH poprzez Eclipse, to kompilacja przebiega prawidłowo. Bez tego kroku kompilacja "sypie" się od razu. Pociągnąłem eksperyment trochę dalej i z PATH usunąłem też wszystkie wystąpienia make.exe czy sh.exe (wywołanie takich nazw z cmd.exe kończy się błędem). Po dodaniu ścieżki do Coreutils (zainstalowanego wg instalatora z mojej stronki) wszystko działa jak trzeba...

    4\/3!!
  • #17
    Dexu
    Level 13  
    Faktycznie paczka Coreutils z Twojej stronki działa, ale musiałem do niej dorzucić dwa pliki DLL:
    libiconv2.dll
    libintl3.dll

    Dorzuciłem je do katalogu bin z twojej paczki, żeby nie tworzyć kolejnych dowiązań PATH. Po tym zabiegu program kompiluje się bez problemu ze slashami i tworzy katalog out (czyli mkdir działa).
    Dodatkowo teraz nie muszę już edytować pliku makefile żeby podać dokładną ścieżkę do pliku.

    Jedyny problem jaki jeszcze został to krok w którym podmieniam pliki wrapera :
    arm-none-eabi-gcc.exe
    arm-none-eabi-objcopy.exe
    arm-none-eabi-objdump.exe

    na orginalne z paczki GCC:

    gcc.exe
    objcopy.exe
    objdump.exe

    Później powalczę jeszcze z tym, ale puki co dzięki wielkie Freedie za pomoc.

    Pozdrawiam
    Dexx
Reply | New topic