Сообщение Re[10]: Питон - уродство от 18.06.2018 0:57
Изменено 18.06.2018 0:58 vdimas
Re[10]: Питон - уродство
Здравствуйте, alex_public, Вы писали:
_>Но в базовой поставке одного из важнейших языков программирования нет — это сразу говорит о направленности данной "системы сборки". )
...
_>Ну ты же понимаешь, что это всё элементарно пишется и единственное отличие CMake заключается в том, что у него подобный модуль уже входит в базовую поставку.
Если в Scons нет модуля под важнейшую либу С++ — это сразу говорит о направленности данной "системы сборки". ))
_>Например у нас (хотя мы используем waf, а не scons, но это не суть) это выглядит так:
_>
_>И кстати при простом внешнем виде это на самом деле внутри весьма не простая штука, т.к. она делает разные настройки в зависимости от целевой архитектуры.
А версии как указать?
А требуемые модули из библиотек для линковщика?
V>>Поэтому, для моего примера надо городить примерно такой огород на SCons:
V>>
V>>Если задать boost_prefix извне в кач-ве аргумента командной строки сборки, то скрипт надо переписывать.
V>>Если задать boost_prefix через переменную среды — скрипт надо переписывать.
V>>Если проводить поиск конкретной версии Boost, то скрипт займёт несколько экранов кода.
_>Ну и замечательно, напиши эти несколько экранов кода один раз, оформи в виде соответствующего модуля (для scons или waf Или GYP или другой системы (я кстати в последнее время стал слышать про некую Meson), не суть) и используй в дальнейшем везде и для всех библиотек.
Это будет несколько экранов кода только чтобы обнаружить Буст нужной версии.
И еще несколько экранов кода, чтобы обыграть упомянутое до этого, плюс требования линковки с нужными либами из Буста.
Еще беда в том, что в Scons нет механизма, позволяющего задать значения переменных извне.
Можно подать аргументы извне, но в переменные ты будешь копировать внешние аргументы ручками.
Итого, самая нужная для целей сборки функциональность (задание внешний параметров для сборки) требует приседания вообще везде, не только для Буста.
_>Да, неплохое решение, но всё равно оно уступает по удобству (естественно только для нас, а не вообще для всех) нашему кастомизированному решению.
Я же не спорю.
У нас поверх CMake тоже сильно кастомизированное решение наверчено.
А так-то, если в конторе проекты типовые, т.е. количество типов проектов не много, то, ИМХО, можно даже без всяких внешних/готовых систем сборки запросто обойтись.
На коленке можно сбацать свою.
_>Например как насчёт ручного управления синхронизацией параллельной сборки?
Чем отличается от "не ручного"?
Я собираю так: make -j 12
Или так: msbuild blah-blah /m:12
Ввиду того, что проекты сгенерены со всеми зависимостями, "синхронизация" получается автоматической.
_>Ну ставятся они из стандартного репозитория Питона одной командой (типа "pip install keyboard").
Это сначала Питон надо установить.
Потом pip.
И только потом нужные библиотеки. ))
Можно было и нейтивную прогу ненамногим большего размера накатать.
SetWindowsHookEx прост в обращении, ему не требуется никакая логика/обвязка, т.е. такая обвязка ничего не экономит.
_>Но в базовой поставке одного из важнейших языков программирования нет — это сразу говорит о направленности данной "системы сборки". )
...
_>Ну ты же понимаешь, что это всё элементарно пишется и единственное отличие CMake заключается в том, что у него подобный модуль уже входит в базовую поставку.
Если в Scons нет модуля под важнейшую либу С++ — это сразу говорит о направленности данной "системы сборки". ))
_>Например у нас (хотя мы используем waf, а не scons, но это не суть) это выглядит так:
_>
_>conf.load_libs('Qt Boost OpenSSL')
_>_>И кстати при простом внешнем виде это на самом деле внутри весьма не простая штука, т.к. она делает разные настройки в зависимости от целевой архитектуры.
А версии как указать?
А требуемые модули из библиотек для линковщика?
V>>Поэтому, для моего примера надо городить примерно такой огород на SCons:
V>>
V>>Что тут не так?V>>import os
V>>env = Environment()
V>>boost_prefix = ""
V>>if is_windows:
V>> boost_prefix = "path_to_boost"
V>>else:
V>> boost_prefix = "/usr" # or wherever you installed boost
V>>env.Append(CPPPATH = [os.path.join(boost_prefix, "include")])
V>>env.Append(LIBPATH = [os.path.join(boost_prefix, "lib")])
V>>app = env.Program(target = "test", source = Source.cpp, LIBS = [. /* тут ручками либы буста указывать надо */..])
V>>env.Default(app)
V>>Если задать boost_prefix извне в кач-ве аргумента командной строки сборки, то скрипт надо переписывать.
V>>Если задать boost_prefix через переменную среды — скрипт надо переписывать.
V>>Если проводить поиск конкретной версии Boost, то скрипт займёт несколько экранов кода.
_>Ну и замечательно, напиши эти несколько экранов кода один раз, оформи в виде соответствующего модуля (для scons или waf Или GYP или другой системы (я кстати в последнее время стал слышать про некую Meson), не суть) и используй в дальнейшем везде и для всех библиотек.
Это будет несколько экранов кода только чтобы обнаружить Буст нужной версии.
И еще несколько экранов кода, чтобы обыграть упомянутое до этого, плюс требования линковки с нужными либами из Буста.
Еще беда в том, что в Scons нет механизма, позволяющего задать значения переменных извне.
Можно подать аргументы извне, но в переменные ты будешь копировать внешние аргументы ручками.
Итого, самая нужная для целей сборки функциональность (задание внешний параметров для сборки) требует приседания вообще везде, не только для Буста.
_>Да, неплохое решение, но всё равно оно уступает по удобству (естественно только для нас, а не вообще для всех) нашему кастомизированному решению.
Я же не спорю.
У нас поверх CMake тоже сильно кастомизированное решение наверчено.
А так-то, если в конторе проекты типовые, т.е. количество типов проектов не много, то, ИМХО, можно даже без всяких внешних/готовых систем сборки запросто обойтись.
На коленке можно сбацать свою.
_>Например как насчёт ручного управления синхронизацией параллельной сборки?
Чем отличается от "не ручного"?
Я собираю так: make -j 12
Или так: msbuild blah-blah /m:12
Ввиду того, что проекты сгенерены со всеми зависимостями, "синхронизация" получается автоматической.
_>Ну ставятся они из стандартного репозитория Питона одной командой (типа "pip install keyboard").
Это сначала Питон надо установить.
Потом pip.
И только потом нужные библиотеки. ))
Можно было и нейтивную прогу ненамногим большего размера накатать.
SetWindowsHookEx прост в обращении, ему не требуется никакая логика/обвязка, т.е. такая обвязка ничего не экономит.
Re[10]: Питон - уродство
Здравствуйте, alex_public, Вы писали:
_>Но в базовой поставке одного из важнейших языков программирования нет — это сразу говорит о направленности данной "системы сборки". )
...
_>Ну ты же понимаешь, что это всё элементарно пишется и единственное отличие CMake заключается в том, что у него подобный модуль уже входит в базовую поставку.
Если в Scons нет модуля под важнейшую либу С++ — это сразу говорит о направленности данной "системы сборки". ))
_>Например у нас (хотя мы используем waf, а не scons, но это не суть) это выглядит так:
_>
_>И кстати при простом внешнем виде это на самом деле внутри весьма не простая штука, т.к. она делает разные настройки в зависимости от целевой архитектуры.
А версии как указать?
А требуемые модули из библиотек для линковщика?
V>>Поэтому, для моего примера надо городить примерно такой огород на SCons:
V>>
V>>Если задать boost_prefix извне в кач-ве аргумента командной строки сборки, то скрипт надо переписывать.
V>>Если задать boost_prefix через переменную среды — скрипт надо переписывать.
V>>Если проводить поиск конкретной версии Boost, то скрипт займёт несколько экранов кода.
_>Ну и замечательно, напиши эти несколько экранов кода один раз, оформи в виде соответствующего модуля (для scons или waf Или GYP или другой системы (я кстати в последнее время стал слышать про некую Meson), не суть) и используй в дальнейшем везде и для всех библиотек.
Это будет несколько экранов кода только чтобы обнаружить Буст нужной версии.
И еще несколько экранов кода, чтобы обыграть упомянутое до этого, плюс требования линковки с нужными либами из Буста.
Еще беда в том, что в Scons нет механизма, позволяющего задать значения переменных извне.
Можно подать аргументы извне, но в переменные ты будешь копировать внешние аргументы ручками.
Итого, самая нужная для целей сборки функциональность (задание внешних параметров для сборки) требует приседания вообще везде, не только для Буста.
_>Да, неплохое решение, но всё равно оно уступает по удобству (естественно только для нас, а не вообще для всех) нашему кастомизированному решению.
Я же не спорю.
У нас поверх CMake тоже сильно кастомизированное решение наверчено.
А так-то, если в конторе проекты типовые, т.е. количество типов проектов не много, то, ИМХО, можно даже без всяких внешних/готовых систем сборки запросто обойтись.
На коленке можно сбацать свою.
_>Например как насчёт ручного управления синхронизацией параллельной сборки?
Чем отличается от "не ручного"?
Я собираю так: make -j 12
Или так: msbuild blah-blah /m:12
Ввиду того, что проекты сгенерены со всеми зависимостями, "синхронизация" получается автоматической.
_>Ну ставятся они из стандартного репозитория Питона одной командой (типа "pip install keyboard").
Это сначала Питон надо установить.
Потом pip.
И только потом нужные библиотеки. ))
Можно было и нейтивную прогу ненамногим большего размера накатать.
SetWindowsHookEx прост в обращении, ему не требуется никакая логика/обвязка, т.е. такая обвязка ничего не экономит.
_>Но в базовой поставке одного из важнейших языков программирования нет — это сразу говорит о направленности данной "системы сборки". )
...
_>Ну ты же понимаешь, что это всё элементарно пишется и единственное отличие CMake заключается в том, что у него подобный модуль уже входит в базовую поставку.
Если в Scons нет модуля под важнейшую либу С++ — это сразу говорит о направленности данной "системы сборки". ))
_>Например у нас (хотя мы используем waf, а не scons, но это не суть) это выглядит так:
_>
_>conf.load_libs('Qt Boost OpenSSL')
_>_>И кстати при простом внешнем виде это на самом деле внутри весьма не простая штука, т.к. она делает разные настройки в зависимости от целевой архитектуры.
А версии как указать?
А требуемые модули из библиотек для линковщика?
V>>Поэтому, для моего примера надо городить примерно такой огород на SCons:
V>>
V>>Что тут не так?V>>import os
V>>env = Environment()
V>>boost_prefix = ""
V>>if is_windows:
V>> boost_prefix = "path_to_boost"
V>>else:
V>> boost_prefix = "/usr" # or wherever you installed boost
V>>env.Append(CPPPATH = [os.path.join(boost_prefix, "include")])
V>>env.Append(LIBPATH = [os.path.join(boost_prefix, "lib")])
V>>app = env.Program(target = "test", source = Source.cpp, LIBS = [. /* тут ручками либы буста указывать надо */..])
V>>env.Default(app)
V>>Если задать boost_prefix извне в кач-ве аргумента командной строки сборки, то скрипт надо переписывать.
V>>Если задать boost_prefix через переменную среды — скрипт надо переписывать.
V>>Если проводить поиск конкретной версии Boost, то скрипт займёт несколько экранов кода.
_>Ну и замечательно, напиши эти несколько экранов кода один раз, оформи в виде соответствующего модуля (для scons или waf Или GYP или другой системы (я кстати в последнее время стал слышать про некую Meson), не суть) и используй в дальнейшем везде и для всех библиотек.
Это будет несколько экранов кода только чтобы обнаружить Буст нужной версии.
И еще несколько экранов кода, чтобы обыграть упомянутое до этого, плюс требования линковки с нужными либами из Буста.
Еще беда в том, что в Scons нет механизма, позволяющего задать значения переменных извне.
Можно подать аргументы извне, но в переменные ты будешь копировать внешние аргументы ручками.
Итого, самая нужная для целей сборки функциональность (задание внешних параметров для сборки) требует приседания вообще везде, не только для Буста.
_>Да, неплохое решение, но всё равно оно уступает по удобству (естественно только для нас, а не вообще для всех) нашему кастомизированному решению.
Я же не спорю.
У нас поверх CMake тоже сильно кастомизированное решение наверчено.
А так-то, если в конторе проекты типовые, т.е. количество типов проектов не много, то, ИМХО, можно даже без всяких внешних/готовых систем сборки запросто обойтись.
На коленке можно сбацать свою.
_>Например как насчёт ручного управления синхронизацией параллельной сборки?
Чем отличается от "не ручного"?
Я собираю так: make -j 12
Или так: msbuild blah-blah /m:12
Ввиду того, что проекты сгенерены со всеми зависимостями, "синхронизация" получается автоматической.
_>Ну ставятся они из стандартного репозитория Питона одной командой (типа "pip install keyboard").
Это сначала Питон надо установить.
Потом pip.
И только потом нужные библиотеки. ))
Можно было и нейтивную прогу ненамногим большего размера накатать.
SetWindowsHookEx прост в обращении, ему не требуется никакая логика/обвязка, т.е. такая обвязка ничего не экономит.