Проблема с GCC, Вчера всё было нормально... Опции

[MrYuran]

Start linking file: Obj/902_430_135.o.
C:\mspgcc\bin\msp430-gcc ./Obj/902_430_135.o ./Obj/ads1241_902.o ./Obj/temperatu
re.o -mmcu=msp430x149 -Wl,--section-start -Wl,.seg_a=0x1080 -Wl,--gc-sections -W
l,-Map=902U.map,--cref -LC:\mspgcc"\bin\lib" -LC:\mspgcc"\msp430\lib" -LC:\mspgc
c"\msp430\include" -LC:\mspgcc"\msp430\include\msp430" -lc -lm -o 902U.elf
/usr/bin/sh: C:mspgccbinmsp430-gcc: command not found
make: *** [902U.elf] Error 127

???
Жирным выделил особо непонятный момент.
Навскидку никто тип грабель не подскажет?

Вот сборочный участок makefile:

Код

# Компиляция: создать объектные файлы из исходников Си.
$(OBJDIR)/%.o: %.c
    @echo Start compile file: $<
    @$(CC) -c $(CFLAGS) $< -o $@
    @echo Compile file: $< - OK.

# Linking.
$(NAME).elf : $(OBJ) makefile
    @echo Start linking file: $<.
    $(CC) $(OBJ) $(LDFLAGS) -o $@
    @echo Linking file: $< - OK.
#
#$(NAME).elf : $(CSRC)
#    @echo $^
#    @$(CC) -c $(CFLAGS) -combine -fwhole-program $^ $(LDFLAGS) -o $(NAME).o
#    $(CC) $(NAME).o $(LDFLAGS) -o $@

$(NAME).a43 : $(NAME).elf
    @$(OBJCOPY) -O ihex $< $@

# Main listing.
$(NAME).lst : $(NAME).elf
    @echo Start create listing file from: $<.
    $(OBJDUMP) -dStl $< > $@
    @echo Create listing file from: $< - OK.

Хотя сомневаюсь, что в нем дело. Точнее, уверен, что не в нем.

Есть предположение, что свежеустановленный цыгвин запускает свой make.exe вместо нужного. Только вот почему ж он такой кривой...
##
Не подтвердилось, с другим то же самое.

>mingw32-make all
Start linking file: Obj/902_430_135.o.
C:\mspgcc3\bin\msp430-gcc ./Obj/902_430_135.o ./Obj/ads1241_902.o ./Obj/temperat
ure.o -mmcu=msp430x149 -Wl,--section-start -Wl,.seg_a=0x1080 -Wl,--gc-sections -
Wl,-Map=902U.map,--cref -LC:\mspgcc3"\bin\lib" -LC:\mspgcc3"\msp430\lib" -LC:\ms
pgcc3"\msp430\include" -LC:\mspgcc3"\msp430\include\msp430" -lc -lm -o 902U.elf
/usr/bin/sh: C:mspgcc3binmsp430-gcc: command not found
mingw32-make: *** [902U.elf] Error 127

##
Внезапное развитие событий.
Залочил цыгвин (переобозвал папку на cygwin_) - всё заработало.
Ну и каким образом он мешается?
И почему вчера (до перезагрузки) всё работало?

Насколько понимаю, он свой sh подставляет вместо системного шелла. Как - в упор не понимаю.

Да, так и есть.
Переобозвал sh.exe в sh_ - всё по-старому, нормально работает.

Каким образом sh включается вместо обычного shell - без понятия.

Сообщение отредактировал MrYuran - May 27 2011, 06:33

[Непомнящий Евген...]

Использую сконс. Доволен!

На мейк в свой время смотрел, но язык уж очень не впечатлил. Кроме того, мейк практически для любых действий зовет внешние программы, у каждой из них своя идеология и свой язык. Учить все это было как-то лениво.

Питоном я кстати заинтересовался, повозюкавшись со сконсом. Язык довольно простой и понятный, включает в себя кучу библиотек для самых разных задач. Многое можно начать делать практически сразу, без долгих разбирательств с языком.

В принципе сконсом можно пользоваться и без знания питона, но часто надо встроить какие-то дополнительные действия в билд, их проще сразу писать на питоне.

По сравнению с мейком, сконс многое умеет из коробки - сборка распространенными компиляторами, использование некоторых внешних программ, автоматическое определение зависимостей от включаемых файлов. Сконс знает, как был скомпилирован каждый файл. Если вы поменяете опции компиляции в скрипте, нужные файлы автоматом перекомпилируются. Не надо делать очистку.

По сравнению с мейком билд скрипт обычно короче (и понятнее).

Очень просто организовать компиляцию одной и той же программы под несколько целевых архитектур разными компиляторами.

Часто используемые действия можно вынести в отдельные файлы и подключать их при необходимости в другие проекты. Также их можно хранить прямо в проекте, в системе контроля версий. При этом много проще собрать старую версию программы.

Минусы сконса проистекают из его плюса - использования полноценного языка программирования:
- ИДЕ не умеют подхватывать билд файлы сконса или автоматически их редактировать
- можно навернуть такого, что посторонний человек (или сам через пару лет) не разберется
- Он сравнительно медленный. Питон - интерпретируемый язык. Кроме того, сконс в отличие от waf многое делает при каждом билде - нет отдельного шага конфигурации.

По довольно большому моему десктопному проекту ребилд выглядит так:
Total build time: 223.119000 seconds
Total SConscript file execution time: 1.909000 seconds
Total SCons execution time: 4.593001 seconds
Total command execution time: 216.616999 seconds

Повторная попытка сбилдить проект (по факту ничего не делается, сконс определяет что нет изменений и завершается):
Total build time: 6.139000 seconds
Total SConscript file execution time: 1.917000 seconds
Total SCons execution time: 4.076000 seconds
Total command execution time: 0.146000 seconds

Однако сконс умеет распараллеливать билд на несколько потоков, а также использовать общий кэш - если у вас несколько (несильно) разных версий проекта используют общий кэш, скорость компиляции сильно вырастет.