Comments 15
Прописывать переменные окружения системы — это из оф мануала такой совет? Выглядит… вообще не очень.
Так же есть легкое пожелание по поводу QMake. Qt официально объявили что главной системой сборки будет CMake. Поэтому крайне желательно современные мануалы адаптировать под него (стандарт де-факто будет сильно грубо сказать?)
Не потому что qmake фу (хотя я бы мог и так сказать), просто подключение внешних таких зависимостей имхо через cmake удобнее и проще чем через qmake. По моему лишь опыту.
use [[maybe__unused]], Luke.
я понимаю есть пуристы, которые набегут и скажут «в стандарте нет никаких ваших #pragma», но лично я их чаяних не разделяю. Если ты не пишешь код который должен работать на 98 платформах, вряд ли стоит отказываться от удобной "#pragma once"
Далее… немного о полезности самой статьи.
Я сомневаюсь что на Хабре найдется много программистов, пишущих на С++, которые не смогут самостоятельно собрать cmake проект. Если никаких нюансов вроде «надо обязательно задать опцию дин. рантайма, иначе нихрена не соберется», то и смысла в статье немного. (разве что ну оооочень начинающим).
Ну и по итогу вся статья в выжимке — сокращается до hello world'a, без каких-то побуждений, что можно делать дальше. Стартовым толчком, на мой взгляд, она служить не может.
Все вышесказанное это только взгляд «как это ощущается» и точно не унижение достоинств автора.
вот пример на мой взгляд ДЕЙСТВИТЕЛЬНО хорошего Hello World:
habr.com/company/newprolab/blog/328422
Так же есть легкое пожелание по поводу QMake. Qt официально объявили что главной системой сборки будет CMake. Поэтому крайне желательно современные мануалы адаптировать под него (стандарт де-факто будет сильно грубо сказать?)
Не потому что qmake фу (хотя я бы мог и так сказать), просто подключение внешних таких зависимостей имхо через cmake удобнее и проще чем через qmake. По моему лишь опыту.
(void) argc;
(void) argv;
use [[maybe__unused]], Luke.
#ifndef MAIN_H
я понимаю есть пуристы, которые набегут и скажут «в стандарте нет никаких ваших #pragma», но лично я их чаяних не разделяю. Если ты не пишешь код который должен работать на 98 платформах, вряд ли стоит отказываться от удобной "#pragma once"
Далее… немного о полезности самой статьи.
Я сомневаюсь что на Хабре найдется много программистов, пишущих на С++, которые не смогут самостоятельно собрать cmake проект. Если никаких нюансов вроде «надо обязательно задать опцию дин. рантайма, иначе нихрена не соберется», то и смысла в статье немного. (разве что ну оооочень начинающим).
Ну и по итогу вся статья в выжимке — сокращается до hello world'a, без каких-то побуждений, что можно делать дальше. Стартовым толчком, на мой взгляд, она служить не может.
Все вышесказанное это только взгляд «как это ощущается» и точно не унижение достоинств автора.
вот пример на мой взгляд ДЕЙСТВИТЕЛЬНО хорошего Hello World:
habr.com/company/newprolab/blog/328422
Обещание выпилить QBS и прикрутить CMake как систему сборки по умолчанию в Qt6 несколько странное и вызвало весьма предсказуемое бурление в рядах сообщества. Посмотрим, чем это кончится, я не удивлюсь, если выпиливание QBS и полная миграция на CMake не состоится.
я понимаю есть пуристы, которые набегут и скажут «в стандарте нет никаких ваших #pragma»
Пуристы набегут, и скажут вам, что первым правилом кроссплатформенной разработки является соблюдение стандартов языка и будут правы
Только ситхи все возводят в абсолют!
Только ситхи
Шутку оценил.
А если по делу — несоблюдение стандарта языка в проекте, позиционируемом как переносимый влечет за собой ряд неприятных граблей, которые вылезают обычно, когда нужно (срочно!) собрать проект под платформу, отличную от той на которой велась разработка. Абсолют тут не причем вообще
Вот из любопытства: на каких платформах, как вы полагаете, читатели данного блога будут компилировать данный проект? Вот я буквально прошу список. Чтобы затем из него вычесть платформы, где эта директива поддерживается. Ну разве что C++ Builder 6 не тянет. Конечно, зависит от целевой аудитории статьи.
Прописывать переменные окружения системы — это из оф мануала такой совет? Выглядит… вообще не очень
В win вообще многие вещи «не очень». Ваши предложения по этому поводу?
Qt официально объявили что главной системой сборки будет CMake
Будет, не значит есть. А что, QtCreator уже поддерживает cmake на уровне добавления файлов в проект? Можно создать новый проект, использующий в качестве системы сборки cmake? Вот когда будет, тогда и поговорим об этом
Стартовым толчком, на мой взгляд, она служить не может
На ваш взгляд не может, а на чей-нибудь другой взгляд — вполне. Вы не один читаете ресурс, верно? К тому же эта не последняя публикация на тему
В win вообще многие вещи «не очень». Ваши предложения по этому поводу?
Обычно все зависимости передаются скрипту конфигурирования в качестве параметров.
1. CMD: в случае autotools/cmake — это параметры/дефайны командной строки. в случае QBS — сеттеры для qml-объектов.
2. GUI, QtC: в случае cmake — есть настройка параметров cmake через редактирование (если они помечены как set… CACHE или option), либо через добавление через GUI. Наряду, кстати с переменными среды. В случае QtC/qbs, это тоже задается через вкладку сборки.
3. Qtc. Если лень в каждую конфигурацию их прописывать, их можно прописать в настройки тулчейна (опять же работает для cmake/qbs) а для QMake — создать отдельный mkspec где нафигачить все переменные которые вам нужны и легко и непринужденно так же указать в kit-е.
4. тот же qtc, в исключительных случаях можно поправить переменные среды (!) во вкладке сборки проекта (все типы систем сборки). Это если ничего не помогло
про другие IDE тоже могу рассказать. Но нигде что-то не встречал я рекомендации «давайте прописывать глобально в системе». Простите, а если я вот хочу две версии мажорных OSG параллельно отлаживать? 2 набора переменных создавать? Постоянно там значения крутить?
Так что я не согласен с вашим выпадом мол на win все такое убогое.
На ваш взгляд не может, а на чей-нибудь другой взгляд — вполне
Ну вот я специально и вставляю оборот, что на мой взгляд, я свое мнение не только высказываю, но и аргументирую. Я же не прошу автора идти совершать соударения со стенами и удалять статью? По-моему вы в этом вопрос слишком болезненно восприняли критику. Кому-то будет полезно — хорошо. Если будут еще публикации — тоже замечательно.
Про CMake и Qtc — не впервой встречаю эту мантру) Тут согласен, что объективной грани нет. Я просто лично не сталкивался с разработчиками, которые пользовались более чем одной системой конфигурирования и при этом признаются что на qmake им писать нравится.
Но!) Хочу с вами поделиться личным опытои: имею множество проектов на CMake, как на работе, так и для личных нужд. При этом не испытываю особых сложностей через добавление в проект файлов с помощью шаблонов (Ctrl+N, Add C++ Class). Да, есть мелкое неудобство что пункт задизаблен в контекстном меню директории проекта. Но это пожалуй все. Открыт у меня какой-то файл, в директории project/foo/bar, нажимаю ctrl+N, выбираю шаблон, он добавляется сразу в foo/bar.
После этого вызываю run cmake (он у меня на хоткей забинден), поэтому сказать что прям IDE заставляет меня страдать — не могу (все это занимает считанные секунды).
Да, люди имеют проекты в которых перечислены файлы, но даже в вашем примере это не так — используется матчинг файлов через $$files. Собственно, для проектов в которых нет глоббинга файлов в любом виде — мой рецепт не поможет =)
Проблема в генерации подходящих дефайнов для Cmake. Особенно когда собираешь франкинштейна из нескольких проектов. Если под *nix пути относительно стандартизированы, то с Windows все сложно и писать в PATH дополнительные, переменные окружения «нормально»
Я бы сказал, что комментатор выше отчасти прав в том, что нужные переменные можно таки прописать в настройках IDE, например. Ну, я как бы и не навязывал именно такой подход
Вот и я о том же. Если в *nix всё лежит в /lib или /usr/lib (и чаще всего с одного на догой путь есть симлинк), то в винде кто во что горазд. У меня была ситуация, когда в системе существовало несколько libpng, и все они попали туда законно — кто с Inkscape, кто c Gimp, кто ещё с чем. И все прописали себя в PATH. В итоге тот же OSG брал непонятно какую библиотеку и давал непонятно какие результаты именно в win. А да, ну это же система для абычнагапользоватиля. Всё для людей…
Если под *nix пути относительно стандартизированы, то с Windows все сложно и писать в PATH
Вот и я о том же. Если в *nix всё лежит в /lib или /usr/lib (и чаще всего с одного на догой путь есть симлинк), то в винде кто во что горазд. У меня была ситуация, когда в системе существовало несколько libpng, и все они попали туда законно — кто с Inkscape, кто c Gimp, кто ещё с чем. И все прописали себя в PATH. В итоге тот же OSG брал непонятно какую библиотеку и давал непонятно какие результаты именно в win. А да, ну это же система для абычнагапользоватиля. Всё для людей…
у меня как-то так до сих пор ахтунг с компиляторами. ставишь mingw, clang и какой-нибудь tcc и просто vs и поди догадайся кто какой версии и из какого места дергает все эти ar.exe ld.exe и прочие. QT Creator позволяет относительно удобно использовать несколько разных компиляторов, но у него тоже свои косяки имеются под windows. Хотя если не изменяет память можно прокинуть и специфичные ENV-параметры по аналогии с системным PATH
Какой-то противоречивый подход у автора туториала: с одной стороны, вроде, нубо-ориентированные пошаговые инструкции в стиле «делай раз, делай два, кликни здесь, впиши вот это вот тут». С другой стороны, навязывание несколько экзотического в своей специфическости тулчейна, при том только потому, что лично автору «для своих проектов необходимо использование компилятора GCC, вернее его варианта MinGW32, входящего в поставку средств разработки фреймворка Qt». Ну, возможно, да — автору для своих проектов замечательно, лучше, чем что бы то ни было, подходит компилятор GCC, но разве этот факт его биографии имеет хоть малейшее отношение к OpenSceneGraph как к таковому?
del
Sign up to leave a comment.
OpenSceneGraph: сборка из исходников и Hello World