На прошлой неделе Кирилл рассказал о своей героической эпопее по переносу Linux приложения на Windows. При этом много копий было сломано в борьбе с различиями в командных строках между компиляторами и линкерами на разных платформах.
К счастью, мне никогда не приходилось переносить приложения с одной операционной системы на другую, однако я решал похожую задачу - построить программу несколькими компиляторами. Меня интересовали: Microsoft Visual Studio и mingw.
Так получилось, что за пару дней до того момента, когда случилось страшное появилась эта задача, мне на глаза попалась ссылка на SCons. Авторы утверждали, что SCons - это улучшенная, кросс-платформенная замена make’у, предоставляющая более простой, надежный и быстрый способ построения приложений из исходников. Забегая вперед, скажу, что с моей задачей СКонсы справились очень даже неплохо!
Итак, давайте попробуем собрать чего-нибудь с помощью СКонсов. Для начала соберем чего-нибудь очень простое - Hello, World! Пусть у нас есть два исходных файла: main.c и main.h, хотим получить helloworld.exe.
В каталоге с исходниками создаем еще один файл SConstruct следующего содержания:
Собственно это - все! Всем строиться (во всех примерах я добавил в командную строчку ключик –Q чтобы сделать Сконсов менее разговорчивыми):
Отлично, удалим построенные файлы:
Переходим к водным процедурам следующему компилятору из списка. Редактируем SConstruct, заменив первую строчку на env = Environment(tools=['mingw']). Строим:
Несложно заметить, что SCons знает основные тонкости каждого из поддерживаемых компиляторов и сам разбирается с правильными ключами командной строки и расширениями объектных и исполняемых файлов.
Дальше - больше. Теперь нам надо построить динамическую библиотеку. Во второй строчке SConstruct’а пишем: env.SharedLibrary(target='helloworld', source=['main.c']). Строим:
Возвращаемся к Visual Studio и строим:
На этом с примерами, пожалуй, всё.
Осталось только добавить несколько слов о других возможностях SCons’ов:
Из грустного: последние версии Intel® Compiler Suite Professional Edition и Intel® Parall Composer не поддерживаются, но предварительные патчи добавляющие поддержку уже проходили в списке рассылки.
Интересно, а вы до сих пор пользуетесь make’ом?
К счастью, мне никогда не приходилось переносить приложения с одной операционной системы на другую, однако я решал похожую задачу - построить программу несколькими компиляторами. Меня интересовали: 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’ом?

Комментарии
Мы - да! :)
Да ладно-ка, - "мы-да" ;). А кто меня SCons'ом еще в ITT мучал?
Точно не я, Дим :)
Я от одного упоминания о сконсе и партсах в силу ряда неразглашаемых причин рожу кривить начинаю :) Возможно, мне стоит пересмотреть эту позицию, но пока что TBB is scons-free software :)
Ну, вот! читал-читал, все казалось простым и понятным, дочитал почти до конца - до латекса и понял, что наверное не понял самого главного: причем здесь LaTeX? Разве, что инструкции с 4х этажными мат. формулами с одной на другую платформы таскать? Разве это так насучно при переноске кода приложений? ;)
у меня cmake, тоже кросплатформенный, хоть и такой нужды нет -- выбор пал не поэтому, а ради удобства
mt2:
с точки зрения билда нет разницы между построением PDF/PostScript из .dvi/.tex и .obj из .cpp
а поскольку пользовательская документация неотъемлемая часть продукта имеет смысл строить ее тем же инструментом.
а к переносимости действительно отношения никакого :)
ilnarb: не холивара ради, на cmake'а я тоже смотрел, но для себя решил что я уже не мальчик еще один скриптовый узкоспециализированный язык учить :)
Дим, Леш
я понимаю что в определенных кругах за одно упоминание сконсов меня могут и канделябрами побить :)
но мой сравнительно небольшой опыт говорит, что для среднего размера приложений тулза неплохо подходит. вон гуглы её для построения Chromium'а используют (http://code.google.com/p/chromium/wiki/ChromiumSoftwareConstructionSystem)
Дима К., да спору нет, просто ты спросил насчёт использования make, я ответил :)
TBB, вероятно, меньше, чем среднего размера приложение. Но у нас причина использования make отчасти в другом - поскольку у нас открытый исходный код, то хотелось минимизировать зависимости от третьесторонних кусков. А GNU make есть практически везде :)
Леш, разумный подход! Тогда возможно имело бы смысл на cmake'а посмотреть. Если не ошибаюсь, он как раз делает нормальные makefile'ы, солюшены и xcode'овые проекты.
хотя, не зря говорят: работает — не лезь.
Страницы