Проектом CopperSpice (http://www.copperspice.com/) развивается графический фреймворк, являющийся ответвлением от Qt 4.8. Целью проекта является переработка кодовой базы для использования шаблонов и новых возможностей стандарта C++11, что позволит полностью избавиться от необходимости применения генератора кода moc (http://doc.qt.io/qt-4.8/moc.html) (Qt Meta-Object Compiler).
Из связанных с использованием moc проблем отмечаются отсутствие поддержки многих аспектов разработки на C++, включая шаблоны, сложные типы данных и статическую проверку типов, а также ориентация на операции строкового сопоставления. Результатом избавления от moc является увеличение производительности приложений, упрощение процесса сборки и возможность выявления большего числа проблем на этапе компиляции. Кроме поддержки возможностей Qt 4.8, в
CopperSpice выполняется портирование и некоторых классов Qt 5. Код распространяется под лицензией LGPL. Для сборки библиотек применяется классический GNU Autotools.
В настоящее время в состав включены следующие библиотеки:
CsCore,
CsGui,
CsMultimedia,
CsNetwork,
CsOpenGL,
CsPhonon,
CsSql,
CsSvg,
CsWebKit,
CsXml и
CsXmlPatterns. Дополнительные библиотеки будут включаться по мере хода разработки.
Следует отметить, что внедрение поддержки C++11 в Qt планируется (http://wiki.qt.io/QtCS2015_ModernCpp) начать в рамках выпуска Qt 5.6. В полной мере реализовать поддержку C++11 в Qt пока не получится из-за ограничений компилятора MSVC, возможность сборки которым является обязательным требованием для обеспечения кросс-платформенности.URL: https://news.ycombinator.com/item?id=9685022
Новость: http://www.opennet.me/opennews/art.shtml?num=42397
Правильная идея, долой костыли. А MSVC - пока доведут вресию с C++11 до production-ready - подтянется. Ну, или не подтянется и придётся под винду чем-то другим собирать.
А ты до этого момента дожить надеешься? Они вон C99 (!!!!) никак сделать не могут нормально. Шестнадцать лет!
Как всегда приятно почитать диванных аналитегов с Опеннета...Вот вам ссылочка, для общего развития, кто чего поддерживает из C++11 и C++14, почитайте на досуге:
Он про C без плюсов. Там действительно все плохо.
> Он про C без плюсов. Там действительно все плохо.По факту и сишники и плюсовики пользующиеся этой дрянью - второй сорт. Можно посмотреть на вмварщиков в MESA как образец. Самые недопрограмеры на весь проект из-за своей вянды и вьюжлстудии. Как по мне так кодовая база MESA здорово улучшилась бы без этого маздайного балласта.
Ты ведь в курсе, что C и C++ -- это 2 разных языка?
> Ты ведь в курсе, что C и C++ -- это 2 разных языка?Я ведь в курсе что если мелкосакс тормозит 16 лет на такой элементарщине, то и на всем остальном будет не сильно лучше.
"Тормозит", боюсь, не то слово. Если мне память не изменяет, они заявили, что Си - язык устаревший и потому они рекомендуют пользоваться C++. Это уже совсем клиника. =/
> Вот вам ссылочка, для общего развития, кто чего поддерживает из C++11 и
> C++14, почитайте на досуге:А смысл? Я показал что мелкосакс может тормозить 16 лет в элементарных фичах - простом си, даже не плюсовом, который проще в 10 раз. А реальный уровень поддержки си и плюсов в MSVS таков, что вмварщики из MESA - откровенный второй сорт, обреченный пользоваться урезанным и древним субсетом стандартов, тогда как все их коллеги с более приличными тулченйами перешли на более новые стандарты.
Без вмтварин и их маздая кодовая база MESA была бы намного лучше. Они единственные кто пользуется бидоноскунсом вместо автотулсов и дреними стандартами ЯП. Виндузоиды - инвалиды от программирования.
Меня просто не особо интересует MSVC. Будут шлангом собирать если что, делов-то.
где-то слышал, что 2015-я студия будет со шлангом из коробки, для кросс-компиляции под айось и андроид
> Будут шлангом собирать если что, делов-то.Ну так особо отчаянные погрызатели кактуса изгаляются нынче с прикручиванием к msvs гцц или шланга. Чтоб поддержку актуальных версий стандартов заиметь.
> C99Но зачем?
Они честно признались (может и не раз), что разрабатывают компилятор C++, а новые и не очень возможности C добавляют лишь потому, что препроцессор по большей части один на двоих. Так что не нужно тыкать в C99, скажите спасибо (если гордость переломите), что есть хотя бы то, что есть. Ну или используйте MinGW/Clang/etc.
> ... А MSVC - пока доведут вресию с C++11 до production-ready - подтянется.Понятно что босяки не могут позволить себе MSDN подписку, но ты бы хоть бесплатный вариант качнул, прежде чем в очередной раз газифицировать лужу.
Давай поделись с окружающими, чего тебе конкретно не хватает в компилере поставляемом с VS2013. Чтобы все поняли насколько реально крут ты сам и насколько убог M$-кий компайлер.
Можешь вот тут почитать:
http://blogs.msdn.com/b/vcblog/archive/2013/12/02/c-11-14-co...
> Можешь вот тут почитать:
> http://blogs.msdn.com/b/vcblog/archive/2013/12/02/c-11-14-co...На дату публикации внимание обращаем: 2 Dec 2013 2:24 PM
Уже VS2015 на подходе, а ты статейки двухлетней давности показываешь.
> Уже VS2015 на подходе,А шо, они таки сделали там C99? Про авангардизм типа C11 я прям и спрашивать стесняюсь, годков через 10 попробую - это ж мелкосакс :)
Ты сам спросил про VS2013, я тебя за язык не тянул.
> Давай поделись с окружающими, чего тебе конкретно не хватает в компилере поставляемом с VS2013.
> Уже VS2015 на подходе, а ты статейки двухлетней давности показываешь.а теперь скажи, что ты программист.
Личкрафтам не хватает, в общем. Чего именно — constexpr и inheriting ctors, например. Были ещё какие-то проблемы с initializer lists, NSDMI и вариадиками, уж не помню точно — под windows таки не я собираю. В итоге это всё счастье собирается (на самом деле уже не собирается) gcc 4.9.
Нашелся тут аналитег.
Пока VS 2012 находится на саппорте 09.01.2018, то библиотека, которая используется большим числом проектов и которая позиционируется как кросплатформенная, должна поддерживать компиляцию этим компилятором.
Свои никому не нужные helloworld-ы можешь компилировать и VS2013.
> числом проектов и которая позиционируется как кросплатформенная, должна поддерживать
> компиляцию этим компилятором.Никто в этом мире никому ничего не должен. Библа кроссплатформенная - пользуйтесь mingw'ом и прочими шлангами. А то что мелкосакс не умеет делать компилеры - их проблемы.
> то библиотека ... которая позиционируется как кросплатформенная, должна поддерживать
> компиляцию этим компилятором.Нет, такая библиотека должна не зависеть от платформенных API и собираться совместимым со стандартами компилятором. Если компилятор платформы от вендора не совместим со стандартами, это не проблема кодовой базы.
> со стандартами компилятором. Если компилятор платформы от вендора не совместим со
> стандартами, это не проблема кодовой базы.В винде по дефолту вообще компиляторов никаких нет. Там компилер какой поставит пользователь. И если кто поставил трэш от микрософта - он сам себе буратино. Мог ставить gcc или шланг, они стандарты поддерживают намного лучше.
Таки, положа руку на сердце, компилятор от вендора может обладать некими ништяками, адекватной поддержкой pdb, например, отсутствием проблем с SDK и так далее.Но я это так, понаслышке только слышал, как-то удаётся удерживаться подальше от этого счастья что по работе, что в хобби.
> Таки, положа руку на сердце, компилятор от вендора может обладать некими ништяками,
> адекватной поддержкой pdb, например, отсутствием проблем с SDK и так далее.Зато сколько я себя помню, в MSVS меня вымораживали десятки разных либ MSVC*.dll, при том угадать какая из есть у пользователя - почти невозможно. А это залет на полноценный setup.exe даже если это сцаный hello world. Если это "отсутствие проблем с SDK" по мнению MS - ну я даже не знаю. И стандарты они плохо поддерживали, еще тогда когда я виндами пользовался. Как я понял, после выхода дотнета на си и плюсы мс просто положил. На си побольше, на плюсы поменьше. Но по их мнению все должны были резко валить на дотнет и только так.
Я под эту хрень не пишу и в ней не работаю - чего ради мне о ней читать? Она меня интересует ровно в том плане, чтобы можно было по-прежнему заявлять о кросспалтформенности софта, использующего этот форк. А будет там msvc или clang - дело двадцать пятое. Поддерживает MSVC 11-е плюсы - и пёс с ним. Не поддерживает - тоже пёс с ним.
А зачем там MSVC? GCC же работает на тех платформах где есть MSVC.
> А зачем там MSVC? GCC же работает на тех платформах где есть
> MSVC.winCE же раньше...
> winCE же раньше...Так сдох же бобик. Куда и дорога.
Я правильно понимаю что форк не будет отдавать авторские права и тем самым ограничит dual licensing?Я честно признаю что в основном пишу сервер-сайд, в теме разбираюсь слабенько... но меня всегда настораживает двойное лицензирование Qt. Интересно какая будет реакция на форк.
В большинстве цивилизованных стран авторские права неотчуждаемы и очень опосредованно связаны с лицензированием. Не нужно путать тёплое с мягким (это в порядке ликбеза).
А по поводу двойного лицензирования - есть и примеры: MySQL, которая также имела двойную лицензию, вполне себе форкнута.
Вы правы, правильней было сказать "имущественные права". Словом "лицензия" не обойдёшься т.к. здесь именно вопрос прав (тот самый copyright, который есть и у GPL программ).Вообще, как раз близость лицензирования Qt к лицензированию MySQL (и других продуктов Oracle) меня и настораживает. Но это уже личное -- просто вы сами упомянули MySQL.:)
На сайте я с первого взгляда вообще не нашёл лицензии. Наверное, она будет если скачать архив с исходниками.
Несогласные со мной люди - пожалуйста, будьте немного более конструктивными. Вопрос имущественных прав проекта CopperSpice мне кажется вполне себе сущностным.
> Несогласные со мной люди - пожалуйста, будьте немного более конструктивными. Вопрос имущественных
> прав проекта CopperSpice мне кажется вполне себе сущностным.какая разница? GPL (LGPL, по‐моему, запамятовал) есть? ну и отлично. а проблемы проприетарщиков — это проблемы проприетарщиков. проприетарщики нам не платят за то, чтобы мы над их проблемами думали.
> Для сборки библиотек применяется классический GNU Autotools.Правильно, зачем нам Windows и кроссплатформенность.
надо форкануть autotools и переписать на bat || vbscript || офисный VBA || powershell
> надо форкануть autotools и переписать на bat || vbscript || офисный
> VBA || powershellНу ты тише, а то накаркаешь. SSH они уже пилят вроде, не прошло и 30 лет :)
В MinGW они доступны сто лет как. Учитывая, что виндузятники один хрен будут тянуть готовые бинарные версии библиотеки - её сборка - это головная боль исключительно авторов проекта. А что винда второстепенной платформой будет - так это только правильно.
Ну да, забрёл к ним на сайт - так и есть. Для винды - MinGW + Clang.
А потом они будут репортить, что не линкуется в вижуалке;)
Да ладно, наверняка совместимо как-то. История извращений ради линковки с уродом от майкрософт давняя, обычно побеждали его.
у msvc, к слову, нет бинарной совместимости между мажорными релизами, а с mingv оно совсем не совместимо. Вариант только если clang начнёт собирать в нужную ABI.
> А потом они будут репортить, что не линкуется в вижуалке;)Ну так им отлупят WONTIX - use mingw/clang, Luke.
Что может быть более прекрасно? Когда у тебя N либ и у какой-то из них нет сорсов, а какие-то из них не собирается с определённым компилятором;)
> Что может быть более прекрасно? Когда у тебя N либ и у
> какой-то из них нет сорсов…то ты кретин, попавший на вендор лок. поздравляю, не надо было жрать кактус.
> что позволит полностью избавиться от mocРазъясните дураку — а сигналы/слоты как?
Такому же дураку объясните, как символьные биндинги сигнлов, сделанные во внешнем .ui файле, например, будут работать.
Я понимаю, шаблонный синтаксис, и все такое, но символьные сигнатуры сигналов-слотов тоже имеют свои преимущества (например, возможность биндить несовпадающие по параметрам методы)
Несовпадающие по параметрам методы вполне можно биндить и на чистом C++. А вот чтобы на символьных сигнатурах понять, что std::string у слота и string вот тут у сигнала вот в этом контексте после using namespace std; — одно и то же, нужно очень сильно постараться.
>а сигналы/слоты как?Вот и посмотрим как. А если сделают красиво и эффективно, то вынесем в отдельную библиотечку и про данный форк благополучно забудем.
Да ладно, зачем так? Хоть кто-то пытается Qt в чувство принести, избавив от костылей и велосипедов.
А можно список из костылей и велосипедов?
сигналы/слоты - нет, не похоже на велосипедизм
"рефлексия" - нет
qtl - нет, или вы не знаете почему она там?кроссплатформенность - ну да, это нужно ломать
новый синтаксис коннектов в compile time, - да, нужно в рантайме как у копроспайса
autotools - да;))) без возможности собрать с Q_NO_FEATURE..
Не несите хернь. Люди заявляют - ни больше, ни меньше - счто проекты с Qt переводятся на эту штуку автоматиыским транслятором. Чего ради вам примерещилось, что уходят в рантайм коннекты и прочее - не знаю, но нет.Сигналы/слоты силами языка - это была чуть ли не первая из демонстраций возможностей C++11.
autotools - да, хорошая и распространённая штука. Мутноватая, но диагностировать проблемы тому, кто сбирает софт, куда лучше, чем у cmake.
А костыли и велосипеды - да половина внутренностекй Qt, начиная с QString. Всё это имело смысл, пока родные библиотеки и компиляторы были хилыми, а сейчас - NIH чистой воды.
>> Чего ради вам примерещилось, что уходят в рантайм коннекты и прочее - не знаю, но нет.дык в презентации у них это написано;)
>> Сигналы/слоты силами языка - это была чуть ли не первая из демонстраций возможностей C++11.
а до 11 версии было значит нельзя, серьёзно?
>> autotools - да, хорошая и распространённая штука. Мутноватая, но диагностировать проблемы тому, кто сбирает софт, куда лучше, чем у cmake.
Мутноватая? То что вы, возможно, осилили одну технологию и не осилили другую, не значит что первая лучше второй, обычное имхо, выпячиваемое дальше чем нужно.
>> А костыли и велосипеды - да половина внутренностекй Qt, начиная с QString
т.е можно прочитать статью на хабре про модные тенденции строк в 2015 году и всё прощай QString. Как там все пропосалы приняли с SSO, string view уже везде поддерживается? Тогда давайте в личкрафты закинем патч с удалением всех QString`ов;)
> Тогда давайте в личкрафты закинем патч с удалением всех QString`ов;)Спасибо, не надо, мне API QString'ов больше нравится, std::string по работе хватает за глаза.
но Crazy Alex я бы попросил создать бранч со сборочными правилами и с инфой сколько это времени заняло;)
Вот, например, как для этого используются variadic templates:
https://bitbucket.org/rndfax/sdp/src/b9450506dc6bb57c17ef8ef...
А вот это приятно: When appropriate, our libraries will use classes from the C++ standard in lieu of reimplementing existing functionality.
>Для сборки библиотек применяется классический GNU Autotools.Совсем поехавшие?
> Совсем поехавшие?Как раз самый нормальный тул. С точки зрения сборщиков и майнтайнеров оно наиболее беспроблемное. Всякие cmake - глюкавят через раз и даже сообщение о том что не так чаще всего отсутствует или неинформативно, а сборка заваливается на середине компиляции. Всякие скунсы и что там еще - вообще жесть и ад.
> Как раз самый нормальный тул.Проверять в 2015-м году наличие какой-нибудь функции, которой не было в одном из видов юникса восьмедисятых — это очень разумно, нужно и полезно!
Иногда ./configure дольше работает, чем сама сборка времени занимает. И не параллелится, насколько я знаю, да.
> С точки зрения сборщиков и майнтайнеров оно
> наиболее беспроблемное.Далеко не все генту-мейнтейнеры с вами согласятся.
> Всякие cmake - глюкавят через раз и даже сообщение
> о том что не так чаще всего отсутствует или неинформативноНапример?
> сборка заваливается на середине компиляции.
Если какой-нибудь Find-модуль не написан или не использован, да. Ну так никто не мешает и в автотулзах не заниматься поиском библиотеки, а просто взять и сделать #include, понадеявшись, что она есть.
>> Как раз самый нормальный тул.
> Проверять в 2015-м году наличие какой-нибудь функции, которой не было в одном
> из видов юникса восьмедисятых — это очень разумно, нужно и полезно!
> Иногда ./configure дольше работает, чем сама сборка времени занимает. И не параллелится,
> насколько я знаю, да.
>> С точки зрения сборщиков и майнтайнеров оно
>> наиболее беспроблемное.
> Далеко не все генту-мейнтейнеры с вами согласятся.Дедфуд, таки для всяких извращений ( и не извращений ) автотулзы с точки зрения манатайнера полезнее, чем весь остальной шлак вместе взятый, хотя бы тем, что если аффтар
проги - школоло, то он не сможет конкретно накосячить в конфигуре. Так как там всего 2 состояния - ниосилили и сделали нормально.
2-я прочина - эстетическая: триплет в тулзах можно недописать, но ревертнуть YES==NO никак, а в этих ваших цмаках так делает каждый 1-й, не считая каждого 2-го. Могу ткнуть в любой произвольный проект на цмаке ;)
Не знаю, как насчёт маинтайнеров, но как пользователь генты я в гробу cmake видел. С autotools, как минимум, сразу видно, что упало - хоть при конфигурировании, хоть при сборке, а вот понять в красивеньком выводе, что не понравилось cmake - это суметь надо.
> Не знаю, как насчёт маинтайнеров, но как пользователь генты я в гробу
> cmake видел. С autotools, как минимум, сразу видно, что упало -
> хоть при конфигурировании, хоть при сборке, а вот понять в красивеньком
> выводе, что не понравилось cmake - это суметь надо.Можно хоть пример такого неинформативного сообщения? Аж самому интересно как автору софтины со сборкой через cmake, а исходный аноним вон не ответил.
Как найдётся примерчик при очередном апдейте - куда кидать? Я ж их не коллекционирую.
> Как найдётся примерчик при очередном апдейте - куда кидать? Я ж их
> не коллекционирую.На гентушную багзиллу.
Не катит - у меня там хоршая смесь размаскированных пакетов, самопальных правленных ебилдов и так далее. Ладно, тебя в сети найти - не проблема.
Запустил компиляцию Линукс = возомнил себя крутым прогером, работающим с БОЛЬШИМИ проектами.Собрал два раз - это уже опыт.
Собрал три раза - это уже стаж. Пора учить прогеров жизни.
А ты даже компиляцию Винды запустить не сможешь ;)
Решать проблему, которую сам себе создал...
> Проверять в 2015-м году наличие какой-нибудь функции, которой не было в одном
> из видов юникса восьмедисятых — это очень разумно, нужно и полезно!Зато у некрофагов с этим древним юниксом (извращенцев хватает) - оно запустится. И может их послать в пешее эротическое, рассказав какое гэ их система. И они будут тихонько чинить свой крап под соответствие актуальному состянию дел, или пойдут лесом. И это лучше чем если эти некрофаги припрутся к автору программы и будут канифолить мозг. А с каким-нибудь cmake обычно получается так что детектирование всего и вся вроде бы проходит успешно, все ЗБС, но на 69% компиляции, через 5 минут прогрева проца, когда юзерь уже пускает слюни на почти готовый бинраь, все вдруг ВНЕЗАПНО заваливается, наконец. А вот в этом месте толпа народа прется к авторам программы и злостно греет мозг.
Поэтому как ни странно, по опыту сборки туевой хучи программ, автотулсы в среднем по больнице - наиболее безграбельны как именно инструмент проверки зависимостей для сборки и дeтeктирования ключевых параметров системы.
> Иногда ./configure дольше работает, чем сама сборка времени занимает. И не
> параллелится, насколько я знаю, да.Но запускается далеко не на каждую сборку (в плане проблемности для разработчика). И по минмуму взлетает на всем где есть позиксный шелл, даже в маздае (с msys или cygwin). И по крайней мере по его отлупу обычно можно понять кто виноват и что делать.
И да, когда компилер 5 минут впахивал для того чтобы на 69% вывалилась наконец не сильно внятная без вчитывания ошибка сборки, суть которой сводится к тому что нужной либы не оказалось - это еще хуже, имхо.
> Далеко не все генту-мейнтейнеры с вами согласятся.
Я компилил достаточно программ под разными системами, чтобы без них оценить "а как оно". Да и вообще, мнение гентушников у которых вообще какой-нибудь там развал портажей по причине "версия бидона не та" не является чем-то из ряда вон - для меня имеет достаточно ограниченную ценность
> Например?
Да хз, какой проект ни ткни, либы детектируются через пень колоду. Я даже затрудняюсь кого-то конкретного выделить - с этим не ахти было вообще у всех. Ну вон vcmi в свое время никак не мог с ffmpeg совладать. Сообщал что все ЗБС, но сборка потом падала где-то на середине.
А если уж мы про многопоточность - make file от cmake выводят в консоль при 8 потоках полное месиво вместо красивого прогресса. А еще там часто бывают race conditions, когда в 1-поточном режиме сборка проходит всегда, а если в 8 потоков фигарить - сборка отлетает с дурной ошибкой без особых причин. И прокатывает раза со второго-третьего. Не совсем понимаю как народ добивается таких красивых гонок. Но если нечто билдуется cmake, оно при многопоточной сборке нередко и ВНЕЗАПНО заваливается в середине сборки, а вывод на консоль при этом отражается лурковским "кровь, кишки, распи...сило".
> не мешает и в автотулзах не заниматься поиском библиотеки, а просто
> взять и сделать #include, понадеявшись, что она есть.Теоретически все вроде бы так. Практически - толи в автотулсах это проще делать, толи еще какие-то факторы. Но факт в том что при сборке программы с автотулсами ВНЕЗАПНО валятся гораздо реже. А когда autotools посылают курить бамбук - обычно он делает это ДО начала сборки и по крайней мере обычно понятно почему. А в случае cmake часто оказывается что в консоли просто месиво, попытки рисовать fancy прогресс только нагибают диагностику, а выглядит это как трэш даже если сборка прошла успешно. Потому что билдовать в 1 поток на 8-ядернике мне как-то не айс, а когда оно в 8 потоков рисует на консоль прогресс без какой либо синхронизации - понятно что получается.
> Зато у некрофагов с этим древним юниксом (извращенцев хватает) - оно запустится.
> И может их послать в пешее эротическое, рассказав какое гэ их
> система. И они будут тихонько чинить свой крап под соответствие актуальному
> состянию дел, или пойдут лесом. И это лучше чем если эти
> некрофаги припрутся к автору программы и будут канифолить мозг.Интересно было бы замерить, сколько ресурсов CPU разработчиков было потрачено зря на общение с некрофилами, а сколько — на ожидание завершения всех этих проверок. Что-то мне подсказывает, что второго таки больше.
> А с
> каким-нибудь cmake обычно получается так что детектирование всего и вся вроде
> бы проходит успешно, все ЗБС, но на 69% компиляции, через 5
> минут прогрева проца, когда юзерь уже пускает слюни на почти готовый
> бинраь, все вдруг ВНЕЗАПНО заваливается, наконец.Тоже мне проблема, доставил либу и дальше себе make, ровно с того же места и продолжит. Если либа не ставится куда-нибудь в странное место, конечно же, что потребует дописывания всяких -I, -L и -l во флаги компилятора и линкера, из-за чего придётся пересобирать уже собранное.
> А вот в этом месте
> толпа народа прется к авторам программы и злостно греет мозг.Думаю, таки не толпа, а полтора мейнтейнера, которым первыми посчастливилось с этим столкнуться.
> Поэтому как ни странно, по опыту сборки туевой хучи программ, автотулсы в
> среднем по больнице - наиболее безграбельны как именно инструмент проверки зависимостей
> для сборки и дeтeктирования ключевых параметров системы.Позвольте полюбопытствовать из общего интереса: а вы их зачем сами столько собираете?
> Но запускается далеко не на каждую сборку (в плане проблемности для разработчика).
Кстати, к слову о каждой сборке, просто из интереса: автотулз может рассчитывать зависимости между файлами в проекте сам, вызывать moc сам когда надо и для чего надо (как AUTOMOC в cmake), пересобирать только нужные .cpp, когда поменялся хедер?
> Я компилил достаточно программ под разными системами, чтобы без них оценить "а
> как оно". Да и вообще, мнение гентушников у которых вообще какой-нибудь
> там развал портажей по причине "версия бидона не та" не является
> чем-то из ряда вон - для меня имеет достаточно ограниченную ценностьВот сколько лет на генте сижу, ничего не разваливалось. И у знакомых ничего не разваливалось. И как-то все эти развалы по причине бидонов проходили мимо меня.
> Да хз, какой проект ни ткни, либы детектируются через пень колоду. Я
> даже затрудняюсь кого-то конкретного выделить - с этим не ахти было
> вообще у всех. Ну вон vcmi в свое время никак не
> мог с ffmpeg совладать. Сообщал что все ЗБС, но сборка потом
> падала где-то на середине.Так либы детектируются не так, или cmake неправильно ругается, когда отсутствие сдетектировалось таки как надо?
> А если уж мы про многопоточность - make file от cmake выводят
> в консоль при 8 потоках полное месиво вместо красивого прогресса.Красивый прогресс — это хорошо, конечно, но мне как-то важнее, чтобы оно быстрее собиралось. Недостаток весьма минорный, ИМХО.
> еще там часто бывают race conditions, когда в 1-поточном режиме сборка
> проходит всегда, а если в 8 потоков фигарить - сборка отлетает
> с дурной ошибкой без особых причин. И прокатывает раза со второго-третьего.Кстати, в cmake с таким не встречался. Про билдсистему того софта, где встречался, впрочем, не помню, были ли это автотулзы или что ещё.
> Не совсем понимаю как народ добивается таких красивых гонок. Но если
> нечто билдуется cmake, оно при многопоточной сборке нередко и ВНЕЗАПНО заваливается
> в середине сборки, а вывод на консоль при этом отражается лурковским
> "кровь, кишки, распи...сило".А при однопоточной при этом всё нормально, не заваливается ничего? Во дела. Прям аж тоже стало любопытно.
> Теоретически все вроде бы так. Практически - толи в автотулсах это проще
> делать, толи еще какие-то факторы. Но факт в том что при
> сборке программы с автотулсами ВНЕЗАПНО валятся гораздо реже.Как-то всё-таки не факт.
Многопоточная сборка обычно ломается там, где криво прописаны зависимости между целями. Чаще всего - когда что-то автогенерится. В cmake действительно бывает геморно генерить зависимости в таких случаях. Как там в autotools - вообще не представляю, не пользовался.
> Что-то мне подсказывает, что второго таки больше.Тут есть некий catch: на диагностику проблем в ручном режиме и потом отсыл этих некрофилов в пешее - потратится время живого человека. А не процессора.
> Тоже мне проблема, доставил либу и дальше себе make,
А зачем cmake тогда занимает место у меня на винте? А если совсем уж хардкорить - так я в принципе и без make file-ов даже обойтись могу. Поставил либы да покомандовал компилером вручную. Неудобно, но работать будет. Вон там автор какой-то проги для тестирования LCDшника - ушибся в край и затребовал scons. Вся прога - 1 тривиальный файл, чуть сложнее hello world. Я почесал репу, проверил наличие libsdl-ных хидеров сам и вкатал gcc команду. Он собрал. И никаких скунсов ставить не надо. Вот зачем так делать, граждане разработчики?
> ровно с того же места и продолжит.
И все это прекрасно, но вообще-то его задача была меня послать ДО начала компила, а не через 5 минут, когда я куда-то переключился...
> во флаги компилятора и линкера, из-за чего придётся пересобирать уже собранное.
Ну так я и вопрошаю: а система сборки и генерации make-файла зачем место у меня на винте занимает тогда?
> Думаю, таки не толпа, а полтора мейнтейнера, которым первыми посчастливилось с этим
> столкнуться.А также те кто попробовал собрать распоследнюю версию на посмотреть. При том у тех кто умеет софт собирать - порой бывают странноватые системы. Какие-нибудь бояздэшники в два счета притащатся с своим окаменелым gcc 4.2, или какой-нибудь старый извращенец с какой-нибудь соляркой попадется. Мало ли.
>> для сборки и дeтeктирования ключевых параметров системы.
> Позвольте полюбопытствовать из общего интереса: а вы их зачем сами столько собираете?С самыми разными целями:
1) Иногда программы может не быть в репах.
2) Или она может быть не той версии. Или опции сборки не по вкусу. Или что там еще.
3) Иногда может захотеться получить программу версии не менее чем эн, с вон той фичой, прямо сейчас, а не когда раздуплятся майнтайнеры. Или напротив - сделать реверт на версию где не было ужасно донимающего бага. Случаи бывают разные.
4) Иногда бывает так что хочется посмотреть на будущее уже сейчас. Возможно вкатав багов до того как проблемный багодром разлетится по дистрам и будет годами иметь мозг юзерью, в том числе и мне.
5) Иногда бывает так что программа ну всем хороша. Но вот эта мелочь - анноит. Или ну самую капельку чего-то не хватает. Можно, блин, пойти и самому это пропатчить. На то оно и опенсорс.
6) А иногда проект и народ в нем может понравиться настолько, что с ними просто нравится работать. При этом я могу и немного коммитов зафигарить. Не то чтобы я великий програмер, но в современном мире как-то очень уж сложно жить, если программить не умеешь. И уж разумеется до этого придется проверить как это компилится.> Кстати, к слову о каждой сборке, просто из интереса: автотулз может рассчитывать
> зависимости между файламиКак таковой некий трекинг зависимостей там есть...
> и для чего надо (как AUTOMOC в cmake), пересобирать только нужные
> .cpp, когда поменялся хедер?...но в такие дебри я не лазил.
> Вот сколько лет на генте сижу, ничего не разваливалось.
Тут наверное еще от прямизны рук и везения зависит. А отдельные маньяки генту на нью-йоркской бирже гоняют, так что в умелых руках и гента - стабильна, иначе бы им финансисты давно что-нибудь открутили. Но такие приколы - имели место быть. И в среднем по больнице редкий псих рискнет вкатить генту на что-то продакшновое...
> Так либы детектируются не так, или cmake неправильно ругается, когда отсутствие
> сдетектировалось таки как надо?Чаще всего - детектируется не так. В смысле, cmake и проц. считает что все ЗБС но в результае оказывается не ЗБС и сборка заваливается на середине. Я даже допускаю что у одного конкретного deadfood cmake работает отлично. Но вот большинство авторов софта почему-то не могут нормально детектировать все либы cmake.
С точки зрения сборки программы это означает что "если программа использует cmake, придется попрыгать по граблям". Поэтому при прочих равных я программу с автокрапом буду собирать - он если завалится то по крайней мере пишет почему. Накрайняк лог есть, где он пишет что делалось. А у cmake сообщения обычно невнятные, часто случается "все ЗБС, но сборка свалилась", а если проверка не прошла - диагностика далеко не всегда очевидна и надо чуть ли не клещами выдергивать недостающее инфо.
> Красивый прогресс — это хорошо, конечно, но мне как-то важнее, чтобы оно
> быстрее собиралось. Недостаток весьма минорный, ИМХО.Ну да. Просто фича из разряда "не умеешь - не берись". Хотели как лучше, с гламурным прогрессом. А в реальности получилось как всегда - многопоточный хаотичный гадеж в консоль мусором. ИМХО лучше бы там без по дефолту рисовался просто вывод компилера: спам примерно одинаково нечитабельный, зато если факап случился - ну хоть диагностика сразу под рукой.
> Кстати, в cmake с таким не встречался. Про билдсистему того софта, где
> встречался, впрочем, не помню, были ли это автотулзы или что ещё.А мне такое попадалось почему-то в основном для софтин с cmake. Хотя, разумеется, проблема потенциально вылезти быть где угодно.
> А при однопоточной при этом всё нормально, не заваливается ничего? Во дела.
> Прям аж тоже стало любопытно.Ну я так понимаю что случаются какие-то гонки. Это наверное не только для cmake характерно, но мне попадалось именно в прогрмамах с ним. Т.к. я не собирал статистику по таким приколам - я не буду настаивать что это эксклюзивная "фича" cmake и тех кто его использует :)
> Как-то всё-таки не факт.
Ну не знаю, мой опыт какой-то вот такой. При том программы с автотулсами были большинством и при более-менее равной проблематичности стало быть и проблем у меня должно было бы быть больше всего именно с автотулсами. А на практике - автотулсы конечно ужасны по внутренностям. Но этот жуткий пи...ц каким-то чудом работает и даже обычно не создает лишних проблем. Хоть я и могу понять антипатии к этому килограмму скриптокостылей, в которые страшно соваться.
>что позволит полностью избавиться от необходимости применения генератора кода mocnice!
>Для сборки библиотек применяется классический GNU Autotools.Молодцы, всё правильно сделали!
Не получится без кастомного препроцессора сделать рефлексию уровня Qt. Сигналы-слоты — более-менее получится, да, а всякие QMetaObject — нет.
как именно сигналы/слоты получится сделать?
Как Boost.Signals или компил-тайм-коннекты из Qt 5.
Так, главный вопрос, они Webkit из Apple-овского транка берут? Если да, то торт!
> Для сборки библиотек применяется классический GNU Autotools.Идиoты которым хватило неадекватности использовать эту мерзость, нормальный продукт никогда не напишут. Закaпываем.
Я не видел более удобной для конечного потребителя системы сборки.
А я не видел более кошмарной. И для потребителя, и для разработчика.
> А я не видел более кошмарной. И для потребителя, и для разработчика.Значит ты еще нихрена не видел, или ты автор шконки.
> А я не видел более кошмарной. И для потребителя, и для разработчика.Для разработчика - может быть. И то - в основном для самих разработчиков автокрапа. А вот с точки зрения пользователей - это единственная среда сборки которая нормально пошлет с внятным сообщением, по минимуму требуя для это только позиксный шелл.
Таки да. Единственная система, где толком видно, что сдохло.
> Таки да. Единственная система, где толком видно, что сдохло.Поддерживаю. У остальных есть все. Кроме нормальной диагностики. А больше оно ни для чего и не требуется...
А как же qml-qtquick - это все?
Это вообще реально реализовать без moc-а?
qml не нужен, очевидно же
А кто заказывает музыку? Без денег сие не взлетит.
>The CopperSpice libraries are a fork of Nokia LGPL Qt 4.8.2То есть они так долго пилят? Когда же они выкатят релиз?
Зачем на QT4 время тратить, лучше QT5 пилить.
КопроСпайс - символично.
MSVC 2015 полностью поддерживает C++11 и почти полностью C++14, так что зря они так
Ебашу на ПРОФТ-5 и горя не знаю.
Учитесь, лузеры:
Действие Начало().
Сообщить("Приветище, друже!"; 64; "Програмджосик").
Конец.
КонецДействия.
Вот и все! А вы все Си, да Си.. Эх, чем бы дитя не тешилось..
Удачи им с их мертворожденным проектом.
> Удачи им с их мертворожденным проектом.Почему вы думаете что данный проект мертворожденный?
>> Удачи им с их мертворожденным проектом.
> Почему вы думаете что данный проект мертворожденный?
>Действие Начало().
> Сообщить("Приветище, друже!"; 64; "Програмджосик").
> Конец.
> КонецДействия.
>Вот и все! А вы все Си, да Си.. Эх, чем бы дитя не тешилось..Это же очевидно ^^
Я джва года осваивал этот язык! Очевидно тебе будет тогда, когда ты код мой прочтешь и хотя бы бегло поймешь, что в нем написано, сынок. Ты не обижайся, все мы когда-то были неопытными кодерами. Но для начала - штанишки подтяни и ПРОФТ подучи, сынуля.
Вот тебе еще, для прокачки скиллов:
Научись-ка, сыночек, сначала сортировку выбором делать, а потом уже пиши сюда:
Предел = 0.
А = 1.
Пока А <= ВсегоЭлементов - 1.
СледЧисло = Числа[А].
СледНомер = А.
Б = А + 1.
Пока Б <= ВсегоЭлементов.
Если Числа[Б] < СледЧисло.
СледЧисло = Числа[Б].
СледНомер = Б.
КонецЕсли.
Б = Б + 1.
КонецПока.
Числа[СледНомер] = Числа[А].
Числа[А] = СледЧисло.
А = А + 1.
КонецПока.
Бджля, не могу без смеха писать, прани простите)))
Но "КонецПока." - меня добил))))))
> Бджля, не могу без смеха писать, прани простите)))
> Но "КонецПока." - меня добил))))))Как не стыдно так нескрьёзно относиться к великому делу сарказма!? :-P
>> Вот тебе еще, для прокачки скиллов:
>> Научись-ка, сыночек, сначала сортировку выбором делать, а потом уже пиши сюда:Халтурщик! Пошёл лёгким путём. Это не выбором, а пузырёк. Немедленно переписать! Бал минус. Кнута на тебя нет. Третьего тома. </>
>Предел = 0.Беспредел?!
Потому, что Qt 4.8.2 вышла 3 года назад, и т.д. и т.п.
> Для сборки библиотек применяется классический GNU Autotools.Приятно что есть ещё адекватные люди, очевидно что и с форком у них всё получится!
Ну всё, жду CopperSpiceCreator, CopperSpiceOs и жесткое финансирование, от которого они обещают не откзываться
> Ну всё, ждуНу всё, ждун. ;-)
Конец QT наверное...
> Конец QT наверное...Сказали же: КонецПока. Не знаю кто такой Пок, но это не Qt.