Кстати о SСons’ах

На прошлой неделе Кирилл рассказал о своей героической эпопее по переносу Linux приложения на Windows. При этом много копий было сломано в борьбе с различиями в командных строках между компиляторами и линкерами на разных платформах.

К счастью, мне никогда не приходилось переносить приложения с одной операционной системы на другую, однако я решал похожую задачу - построить программу несколькими компиляторами. Меня интересовали: Microsoft Visual Studio и mingw.

Так получилось, что за пару дней до того момента, когда случилось страшное появилась эта задача, мне на глаза попалась ссылка на SCons. Авторы утверждали, что SCons - это улучшенная, кросс-платформенная замена make’у, предоставляющая более простой, надежный и быстрый способ построения приложений из исходников. Забегая вперед, скажу, что с моей задачей СКонсы справились очень даже неплохо!

Итак, давайте попробуем собрать чего-нибудь с помощью СКонсов. Для начала соберем чего-нибудь очень простое - Hello, World! Пусть у нас есть два исходных файла: main.c и main.h, хотим получить helloworld.exe.
В каталоге с исходниками создаем еще один файл SConstruct следующего содержания:
env = Environment()
env.Program(target='helloworld', source=['main.c'])

Собственно это - все! Всем строиться (во всех примерах я добавил в командную строчку ключик –Q чтобы сделать Сконсов менее разговорчивыми):
D:\python\scons>scons -Q
cl /Fomain.obj /c main.c /nologo
main.c
link /nologo /OUT:helloworld.exe main.obj

Отлично, удалим построенные файлы:
D:\python\scons>scons -Q -c
Removed main.obj
Removed helloworld.exe

Переходим к водным процедурам следующему компилятору из списка. Редактируем SConstruct, заменив первую строчку на env = Environment(tools=['mingw']). Строим:
D:\python\scons>scons -Q
gcc -o main.o -c main.c
gcc -o helloworld.exe main.o

Несложно заметить, что SCons знает основные тонкости каждого из поддерживаемых компиляторов и сам разбирается с правильными ключами командной строки и расширениями объектных и исполняемых файлов.

Дальше - больше. Теперь нам надо построить динамическую библиотеку. Во второй строчке SConstruct’а пишем: env.SharedLibrary(target='helloworld', source=['main.c']). Строим:
D:\python\scons>scons -Q
gcc -o main.o -c main.c
gcc -shared -o helloworld.dll main.o -Wl,--out-implib,libhelloworld.a
Creating library file: libhelloworld.a

Возвращаемся к Visual Studio и строим:
D:\python\scons>scons -Q
cl /Fomain.obj /c main.c /nologo
main.c
link /nologo /dll /out:helloworld.dll /implib:helloworld.lib main.obj

На этом с примерами, пожалуй, всё.

Осталось только добавить несколько слов о других возможностях SCons’ов:

  • SConstruct - это обычный Python’овый скрипт, поэтому в нем можно пользоваться всеми прелестями нормального языка программирования

  • Умеем из коробки: C, C++, D, Java, Fortran, Yacc, Lex, Qt, SWIG. Плюс есть возможность генерации TeX и LaTeX документов.

  • Поддерживаются параллельные билды.


Из грустного: последние версии Intel® Compiler Suite Professional Edition и Intel® Parall Composer не поддерживаются, но предварительные патчи добавляющие поддержку уже проходили в списке рассылки.

Интересно, а вы до сих пор пользуетесь make’ом?
Теги:
Пожалуйста, обратитесь к странице Уведомление об оптимизации для более подробной информации относительно производительности и оптимизации в программных продуктах компании Intel.

Комментарии

Аватар пользователя Alexey Kukanov (Intel)

Мы - да! :)

Аватар пользователя Dmitry Oganezov (Intel)

Да ладно-ка, - "мы-да" ;). А кто меня SCons'ом еще в ITT мучал?

Аватар пользователя Alexey Kukanov (Intel)

Точно не я, Дим :)
Я от одного упоминания о сконсе и партсах в силу ряда неразглашаемых причин рожу кривить начинаю :) Возможно, мне стоит пересмотреть эту позицию, но пока что TBB is scons-free software :)

Аватар пользователя mt2

Ну, вот! читал-читал, все казалось простым и понятным, дочитал почти до конца - до латекса и понял, что наверное не понял самого главного: причем здесь LaTeX? Разве, что инструкции с 4х этажными мат. формулами с одной на другую платформы таскать? Разве это так насучно при переноске кода приложений? ;)

Аватар пользователя Ilnar

у меня cmake, тоже кросплатформенный, хоть и такой нужды нет -- выбор пал не поэтому, а ради удобства

____________________ Борханов Ильнар
Аватар пользователя Dmitry Kozlov (Intel)

mt2:
с точки зрения билда нет разницы между построением PDF/PostScript из .dvi/.tex и .obj из .cpp
а поскольку пользовательская документация неотъемлемая часть продукта имеет смысл строить ее тем же инструментом.

а к переносимости действительно отношения никакого :)

-- DmK
Аватар пользователя Dmitry Kozlov (Intel)

ilnarb: не холивара ради, на cmake'а я тоже смотрел, но для себя решил что я уже не мальчик еще один скриптовый узкоспециализированный язык учить :)

-- DmK
Аватар пользователя Dmitry Kozlov (Intel)

Дим, Леш

я понимаю что в определенных кругах за одно упоминание сконсов меня могут и канделябрами побить :)

но мой сравнительно небольшой опыт говорит, что для среднего размера приложений тулза неплохо подходит. вон гуглы её для построения Chromium'а используют (http://code.google.com/p/chromium/wiki/ChromiumSoftwareConstructionSystem)

-- DmK
Аватар пользователя Alexey Kukanov (Intel)

Дима К., да спору нет, просто ты спросил насчёт использования make, я ответил :)

TBB, вероятно, меньше, чем среднего размера приложение. Но у нас причина использования make отчасти в другом - поскольку у нас открытый исходный код, то хотелось минимизировать зависимости от третьесторонних кусков. А GNU make есть практически везде :)

Аватар пользователя Dmitry Kozlov (Intel)

Леш, разумный подход! Тогда возможно имело бы смысл на cmake'а посмотреть. Если не ошибаюсь, он как раз делает нормальные makefile'ы, солюшены и xcode'овые проекты.

хотя, не зря говорят: работает — не лезь.

-- DmK

Страницы