четверг, ноября 24, 2011

Оказывается, умер Ритчи

Для меня это исключительно печальное событие. Джобс не существовал в моём сознании как человек. А Ричи - существовал. По голубой книге издательства Мир в 90м году я начал изучать "серьёзный язык". Начал в 90м, а последнюю строчку на нём написал 20 минут назад.

Земля тебе пухом, Дэн. Ты всё изменил для меня и сотен тысяч других обормотов.

четверг, октября 27, 2011

Маленькие извращенцы из группы разработки MSBUILD

Я очень недоволен. Передо мной стоит задача, похоже неразрешимая в принципе. Один из наших продуктов должен собираться в 4х конфигурациях (да ещё и для двух серверов - тестового и production). Там много всего внутри. И asp.net, и сервисы, и серверы и чего только там нет. При этом используются одновременно очень разные технологии. В том числе - С++. Поскольку сиплюсплюсный бог велел нам пользовать условную компиляцию, то код вроде


#ifdef _DEBUG
#define LIC_SERV "127.0.0.0"
#else
#define LIC_SERV "207.46.232.182"
#endif

не только не редкость, а само собой.

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

Независимый сборщик собирать будет так:
msbuild proj.build /p:General=true|false /p:Debug=true|false /p:Public=true|false

внутри proj.build каждый из переданных параметров-свойств /p будет обработан и на его основе будет что-то сделано, например

<propertygroup condition="'$(Debug)'=='true'"> 
  <defineconstants>$(DefineConstants);DEBUG
</propertygroup>
И так далее и такого много. Так вот, в чём проблема. А она в том, что можно хоть жирным красным писать

msbuild proj.build /p:General=false /p:Debug=false /p:Public=true|false

это никак не повлияет на отношения msbuild и cl. Константы не передаются как аргументы ключа /D компилятору.

Нам предлагают писать отдельностоящие страницы свойств, определять CL через SET (тоже не особо-то и работает) и тому подобные элегатные решения.

У меня только один вопрос. Ладно, есть отдельные криворукие уроды, которые не в состоянии предоставить своему "революционно-удобному средству сборки" одинаковые механизмы использования любых стандартных компиляторов, ладно, есть маркетологи, которые традиционно понимают чуть больше чем 0 в том, что продают. Но должен же в микрософте быть какой-то отдел по контролю качества. Интернет плачет и рыдает - никто не может корректно определить макросы с++ компилятора для передачи их msbuild в командной строке, а этим хоть бы что.

Ну как там можно, ёшкин КодтЪ

P.S. Забыл написать. Решается эта проблема так:

msbuild client\client.vcxproj /p:configuration=debug /p:platform=win32
Тут указывается, что будет собираться DEBUG-конфигурация и одно определение уже, считай, есть. То есть, ветки #if DEBUG будут активизированы. А вот с General - пришлось писать отдельный файл, менять его перед компиляцией отдельной карликовой утилиткой (пришлось самому писать)... В общем, буэээ