Простите за едкость, у вас-то есть коммерчески успешный продукт, в котором вы продолжаете поддерживать версии вышедшие 20 лет назад? Если да, скиньте ссылочку, будет интересно.
Вам никто не запрещает пользоваться ХР до сих пор. Просто почему бы например Win2000 не поддерживать в новой IDE? или Win95? где-то же должен быть предел.
Поддержка ХР была рекордно длительное время, но это не может продолжаться вечно.
Это не просто прихоть маркетинга (иначе бы выкидывали поддержку всего кроме вин10), с т.зр. разработки реально приходится сталкиваться с ограничениями в API. попробуйте-ка всякие TLS и shared_mutex реализовать, когда нативной поддержки нормальной нет)
Релиз не тестил еще, но TP были тормознее. Обещали какие-то оптимизации по скорости.
механизмов обратной совместимости компиляторов и IDE
Обратная совместимость как раз есть — вы можете в новой IDE переключать на тулсеты старых компиляторов.
А то что вы хотите, это называется прямая, и ее не так просто реализовать.
Представьте, запустили вы новый компилятор, а подсветка кода не работает =) Это очень сильно ударит по имиджу «поддержки» такой фичи. А модель кода портировать в старые версии — это может быть половину кода IDE затрагивать)
(ну и да, тут еще финансовая сторона — скорее всего, продажи бы упали раз так в ндцать, т.к. многие компании покупают лицензии только ради компилятора).
Самый главный вопрос, который сейчас волнует нашу команду — в блоге была упомянута обратная совместимость между v140 и v142 тулсетами, т.е. можно в коде, скомпиленном с v142, использовать библиотеки с v140 (vs2015).
А есть ли совместимость с v140_xp библиотеками? Формально, проект собирается и бинарники запускаются, но гарантируется ли какая-то работоспособность? Очень хочется получить ответ, пересобрать все зависимости за раз не хочется.
p.s. не уверен, правда, по месту ли это не в профильном блоке MS спрашивать. Но вдруг кто из коллег уже озадачивался этим вопросом.
А если чувство стыда отсутствует вовсе? Я дебил теперь что ли?
Я вот смотрю исходники которые писал в школе, да, я сейчас пишу намного лучше, да я бы сейчас так не писал, местами код неоптимальный, а местами дико смешной)
Но мне не стыдно, т.к. я понимаю что я бы тогда не написал лучше. Чего этого стыдиться?
Это все равно что стыдиться детских рисунков, или там первого юношеского стихотворения.
Неужели кто-то глядя на такое может составить мнение о сегодняшнем человеке?
Если мне HR скажет «вы знаете мы на просторах инета нашли ваш сайт 2004 года, и там скачали rar с исходниками, боже, какая оборжака» я просто не буду с ними иметь дело.
Какой стыд вообще?
Резонно. В таком случае выражаю свое фи пиарщикам.
Конечно, Devuan они пока не переплюнули по идиотизму, но лучше уж вообще не шутить, чем так. Опять же только мое мнение, может зашло кому.
Я на протяжении нескольких лет сохранял директорию в /home/, а потом забил и теперь при обновлениях начинаю все с чистого листа. Не надо париться «ой а вдруг какая персональная информация потеряется».
кхм-бола? это вы завуалировали так «пиздабола»?
Очень вежливо с вашей стороны, ничего не скажешь, следите за тоном.
В чем вопрос? Сомнения в том, какую должность/зарплату я занимаю? может быть еще и фото расчетного листка приложить для вас?))
Может я некорректно выразился, поясню мысль: я по большей части разрабатываю софт, но нередко приходится писать и документацию, и спецификации, и мне реально нравится это делать (но не могу поручиться, что я был бы рад ТОЛЬКО этим заниматься каждый день весь год). Намек был лишь только на то что все люди разные, и утверждать, что все прям сознательно отлынивают от написания доки, как-то чересчур категорично.
Грустненько, что сразу расстроило — помимо переписывания проектов, конечно — нет никакой интеграции с MSVS (не Code) и XCode (вернее, уже для xcode есть beta. не затестил еще).
Нет, спасибо, у него вагон минусов. Я писал проект Wuild как замена Incredibuild прежде всего. Мы им пользовались в течение двух лет примерно. Ну и да, он мало того что платный, у них еще конская политика лицензирования)
И да, у меня получилось сборку сделать быстрее чем с Incredibuild, в первую очередь в сценарии инкрементной сборки.
Спасибо, интересно, гляну обязательно, на Bazel не натыкался, и в моей статье про распределенную сборку тоже про него не упомянули)
Из минусов — то что надо писать новые правила, если проект уже имеет вагон cmake скриптов, портировать может быть затратно.
Я в основном затачивался под связку cmake+ninja, чтобы ничего в проекте менять не надо было)
Стомегабитной сетки вполне достаточно для рапределённой сборки.
Я собираю дома через VPN 35 мб сеть, все равно локальные ресурсы используются полностью)
Итоговое время по wall clock ненамного выше чем при сборке из офиса (на 10-15%), ну а так, время исполнения одной задачи конечно выше, сетевой оверхед до 40-50% по времени доходит.
И да, я собираю дебажный билд, итоговый размер директории сборки около 5 Гб выходит (хотя если у вас проект в дебаге гигов по 100 имеет, как хромиум какой-то, то наверное да, скорость уже начинает дико решать).
… и все равно это не учтет такой сценарий:
допустим у нас есть 2 билда, 100 ядер в кластере, ну и проект ясен пень уже идеально распараллен, с использованием всех ядер проблем нет.
QA ставят сборки почти одновременно;
— на первом билде сборка стартует, «спрашивает» как вы говорите количество свободных ядер, передает 100 в make, сборка начинается, ядра отмечаются как занятые;
— стартует второй билд, запрашивает удаленные ядра, их 0, поэтому сборка идет чисто локально (j 16 или j 32, сколько у нас там локальных ядер на билде)
— первая сборка через полминуты сваливается с ошибкой компиляции (да или просто завершается потому что билдили небольшой проект), второй билд курит бабмук =)
Еще раз говорю, чтобы максимально эффективно это делать, планировщик системы сборки и распределенной должен быть объединен =)
И нет, я не выдумываю сценарии на ходу, я реально решал такие проблемы в своем проекте, когда идут релизы, сборки ставятся очень часто.
На мой взгляд, главный минус и distcc, и icecc — то что нет тесной интеграции с системой сборки (make/ninja). Т.о. при запуске make нужно заранее знать сколько потоков параллелить (а если сборка запускается на двух машинах/билдах, то по факту они обе могут драться за одно и то же количество удаленных потоков — просто писать -j 150 может быть совершенно бессмысленно. )
А еще представьте, что у вас сборочный кластер например из 8 машин по 24 ядра, и 5 сборочных серверов, на каждом из которых может идти несколько сборок.
Какой -j там передавать наиболее эффективно? это нерешаемая задача)
make и ninja начинают адово тупить, если считают что компоновать надо в стопицот потоков…
А если распределенную сборку интегрировать внутрь системы сборки, планировщик может учитывать как локальные ресурсы (препроцессинг и линковка), так и удаленные :)
Эх, сперва обрадовался, что еще одна замена distcc подъехала, а потом посмотрел и расстроился, что по факту поддержка тех же самых платформ.
У кого-нибудь получалось distcc или ice завести под Cygwin, поделитесь?
Хотя в первую очередь интересно, конечно, распределение сборки MSVC =)
(Ясен пень, у меня есть моя система распределённой сборки Wuild, которая это все поддерживает, но интересны же конкурирующие решения)
Вам никто не запрещает пользоваться ХР до сих пор. Просто почему бы например Win2000 не поддерживать в новой IDE? или Win95? где-то же должен быть предел.
Поддержка ХР была рекордно длительное время, но это не может продолжаться вечно.
Это не просто прихоть маркетинга (иначе бы выкидывали поддержку всего кроме вин10), с т.зр. разработки реально приходится сталкиваться с ограничениями в API. попробуйте-ка всякие TLS и shared_mutex реализовать, когда нативной поддержки нормальной нет)
Релиз не тестил еще, но TP были тормознее. Обещали какие-то оптимизации по скорости.
Обратная совместимость как раз есть — вы можете в новой IDE переключать на тулсеты старых компиляторов.
А то что вы хотите, это называется прямая, и ее не так просто реализовать.
Представьте, запустили вы новый компилятор, а подсветка кода не работает =) Это очень сильно ударит по имиджу «поддержки» такой фичи. А модель кода портировать в старые версии — это может быть половину кода IDE затрагивать)
(ну и да, тут еще финансовая сторона — скорее всего, продажи бы упали раз так в ндцать, т.к. многие компании покупают лицензии только ради компилятора).
А есть ли совместимость с v140_xp библиотеками? Формально, проект собирается и бинарники запускаются, но гарантируется ли какая-то работоспособность? Очень хочется получить ответ, пересобрать все зависимости за раз не хочется.
p.s. не уверен, правда, по месту ли это не в профильном блоке MS спрашивать. Но вдруг кто из коллег уже озадачивался этим вопросом.
Я вот смотрю исходники которые писал в школе, да, я сейчас пишу намного лучше, да я бы сейчас так не писал, местами код неоптимальный, а местами дико смешной)
Но мне не стыдно, т.к. я понимаю что я бы тогда не написал лучше. Чего этого стыдиться?
Это все равно что стыдиться детских рисунков, или там первого юношеского стихотворения.
Неужели кто-то глядя на такое может составить мнение о сегодняшнем человеке?
Если мне HR скажет «вы знаете мы на просторах инета нашли ваш сайт 2004 года, и там скачали rar с исходниками, боже, какая оборжака» я просто не буду с ними иметь дело.
Какой стыд вообще?
Конечно, Devuan они пока не переплюнули по идиотизму, но лучше уж вообще не шутить, чем так. Опять же только мое мнение, может зашло кому.
Очень вежливо с вашей стороны, ничего не скажешь, следите за тоном.
В чем вопрос? Сомнения в том, какую должность/зарплату я занимаю? может быть еще и фото расчетного листка приложить для вас?))
Может я некорректно выразился, поясню мысль: я по большей части разрабатываю софт, но нередко приходится писать и документацию, и спецификации, и мне реально нравится это делать (но не могу поручиться, что я был бы рад ТОЛЬКО этим заниматься каждый день весь год). Намек был лишь только на то что все люди разные, и утверждать, что все прям сознательно отлынивают от написания доки, как-то чересчур категорично.
И да, у меня получилось сборку сделать быстрее чем с Incredibuild, в первую очередь в сценарии инкрементной сборки.
Из минусов — то что надо писать новые правила, если проект уже имеет вагон cmake скриптов, портировать может быть затратно.
Я в основном затачивался под связку cmake+ninja, чтобы ничего в проекте менять не надо было)
Я собираю дома через VPN 35 мб сеть, все равно локальные ресурсы используются полностью)
Итоговое время по wall clock ненамного выше чем при сборке из офиса (на 10-15%), ну а так, время исполнения одной задачи конечно выше, сетевой оверхед до 40-50% по времени доходит.
И да, я собираю дебажный билд, итоговый размер директории сборки около 5 Гб выходит (хотя если у вас проект в дебаге гигов по 100 имеет, как хромиум какой-то, то наверное да, скорость уже начинает дико решать).
допустим у нас есть 2 билда, 100 ядер в кластере, ну и проект ясен пень уже идеально распараллен, с использованием всех ядер проблем нет.
QA ставят сборки почти одновременно;
— на первом билде сборка стартует, «спрашивает» как вы говорите количество свободных ядер, передает 100 в make, сборка начинается, ядра отмечаются как занятые;
— стартует второй билд, запрашивает удаленные ядра, их 0, поэтому сборка идет чисто локально (j 16 или j 32, сколько у нас там локальных ядер на билде)
— первая сборка через полминуты сваливается с ошибкой компиляции (да или просто завершается потому что билдили небольшой проект), второй билд курит бабмук =)
Еще раз говорю, чтобы максимально эффективно это делать, планировщик системы сборки и распределенной должен быть объединен =)
И нет, я не выдумываю сценарии на ходу, я реально решал такие проблемы в своем проекте, когда идут релизы, сборки ставятся очень часто.
p.s. вот например как я это с ninja интегрировал:
github.com/mapron/Wuild/blob/master/3rdparty/ninja-1.8.2/src/build.cc#L730
А еще представьте, что у вас сборочный кластер например из 8 машин по 24 ядра, и 5 сборочных серверов, на каждом из которых может идти несколько сборок.
Какой -j там передавать наиболее эффективно? это нерешаемая задача)
make и ninja начинают адово тупить, если считают что компоновать надо в стопицот потоков…
А если распределенную сборку интегрировать внутрь системы сборки, планировщик может учитывать как локальные ресурсы (препроцессинг и линковка), так и удаленные :)
У кого-нибудь получалось distcc или ice завести под Cygwin, поделитесь?
Хотя в первую очередь интересно, конечно, распределение сборки MSVC =)
(Ясен пень, у меня есть моя система распределённой сборки Wuild, которая это все поддерживает, но интересны же конкурирующие решения)