Какой лучший workflow работы с git subtree?

Александр, извините за безнадёжно запоздалый ответ) Рассылка Тостера подключена к почте, которую я уже почти не использую. На всякий случай - вот ссылка на соответствующий раздел статьи.

Как правильно организовать модульный проект с использованием CMake?

Большое спасибо за развёрнутый ответ и, главное, за ссылки! Хорошо что CMake развивается - новое API выглядит куда разумнее существующего.

Остались некоторые вопросы - но, думаю, статьи по вашим ссылкам ответят на них.

Как и куда писать статьи с собственными размышлениями?

Хомон, напишите в ответы на вопрос, а не в комментарии - укажу как решение... Что-то я запутался в системе ответов/комментариев на Тостере)

Как и куда писать статьи с собственными размышлениями?

Александр Скуснов, хотя этот вариант ближе к тому, что может получиться (во всяком случае, в статье про метаданные) - и тут аудитория приняла намного прохладнее... Но тоже не сказать что совсем-совсем плохо. Короче, буду работать.

Как и куда писать статьи с собственными размышлениями?

Александр Скуснов, хорошо) Я вот уже почти решился целясь на хабру писать - вспомнил о том, что там таки были такие рисковые статейки. Например - вообще статья-ответ на другую статью.

Как и куда писать статьи с собственными размышлениями?

SmInc, я не ради репутации и признания писать хочу) Реально интересно обсудить несколько тем -
(1) возможный взгляд на построение архитектуры UI, (2) парсинг текста автоматами в обобщённом виде, (3) графические языки для описания цепочек обработки данных и (4) взгляд на метаданные и механизм работы с ними.

Просто есть сомнение как бы не вышло глупость сморозить. Судя по тому, что находил - вроде, нормальный материал, обсудить имеет смысл... Но не уверен насколько это по формату Хабре подойдёт. Выше вон Гиктаймс советовали - может, действительно туда?

Как организовать React шаблоны в отдельных файлах?

rakro: оживлю этот тредик... Перехожу с С++ (Qt, самый популярный UI-фреймворк на С++) на веб и выбираю сейчас между Angular и React. Задавался, в частности, тем же вопросом что автор.

Как я понимаю, слой декларативного описания UI позволяет сделать проще разделение работ по вёрстке и программированию. Дизайнер/верстальщик может сам поправить какие-нибудь свойства UI в файлах декларативного описания UI без необходимости дёргать по этому поводу программистов или лезть в код. Работает принцип инкапсуляции - в данном случае разделение областей ответственности в команде разработки. В том же Qt есть свой язык декларативного описания UI - QML - и в целом наблюдаются тенденции по переходу к декларативному подходу.

Поэтому, ИМХО, заданый вопрос не праздный. По крайней мере, если в React нет шаблонов - интересно было бы понять как организовать workflow дизайнеров. Пускать их в коде шариться?

Основные отличия habraharb, geektimes и megamozg?

Можно ещё вопрос задать? Вот я заканчиваю статью о шагах для публикации open source библиотеки: выбор лицензии, подготовка кода для публикации, организация репозитория, и.т.д. При этом статья входит в небольшой цикл о моей библиотек и первая статья цикла сугубо программерская, с детальным разбором истории создания кода (и потому будет на хабре).

Заранее приношу свои извинения если вопрос не по месту и/или не по адресу; если так, подскажите, если будет возможность, у где/у кого лучше спросить? Заранее спасибо за ответ!

Как правильно организовать проект, выкладываемый в open source?

Станислав Макаров: ясно. теперь стало понятно - абстрагирование от места расположения библиотек выполняется за счёт использования make-системы. Думаю, теперь вопрос можно считать исчерпанным. Огромное спасибо за очередной подробный ответ и за потраченное на меня время! В этом смысле я верю в законы кармы - уверен, кто-нибудь когда-нибудь столь же подробно просветит и вас в каких-нибудь вопросах )!.. Ну, и с меня ссылка на статью про опубликованную библиотеку - я над ней работаю в данный момент.

Как правильно организовать проект, выкладываемый в open source?

Станислав Макаров: (edited) Огромное спасибо за продолжаете высказывать свои мысли! Для меня, как для новичка в этом деле, очень важный опыт... Как буду писать статью про либу - обязательно вас упомяну.

Мои неуклюжие мысли по порядку (заранее извиняюсь что так много - просто хочется понять как умные люди вопросы решают):

-------------------------------------------
"Речь все-таки о том, чтобы научиться передавать компилятору ключи с путями к инклудам и lib-ам"

Идею насчёт инклуд-пасов понял, кажется. То есть, когда нам нужно подключить библиотечку, делаем следующую штуку:
1. Скачиваем репозиторий библиотечки, который организован так, как я описал в вопросе.
2. Добавляем папку include скаченного репозитория в перечень inlcude-пасов для своего проекта. Если в репозитории есть папка libs - добавляем её в перечень путей -L (или как там оно: пути, по которым ищутся библиотеки для линкера). Если библиотеки в репе нету - собираем её с помощью make-файла в репе, кладём в свою папочку libs (или в такую папку в рамках скаченной репы, .gitignore), после чего ссылу на эту папочку добавляем в проект.

Звучит неплохо... Но есть одно но. Как прописывать include-пасы в таком случае? Я так понимаю, все скачиваемые либы в одном месте при этом лежать будут, не в рамках проекта? Относительно путь прописать нельзя по понятным причинам. А если прописывать абсолютно - не ясно как другим людям использовать проект с такой организацией сборки у себя на компах.

Можно, конечно, system vars использовать (я про винду сейчас): создать переменную среды в духе "all_libs" с путём к месту выкладывания всех сторонних реп и относительно неё пасы прописывать (%all_libs%\< lib_name >\include) - но это как-то немного неуклюже выглядит, на мой взгляд: в основном потому, что требует манипуляций с системой на машине каждого из скачивающих твою репу с зависимостями.

Или я, возможно, опять что-то не так понял? Давайте ещё структуру организации рабочего пространства на компьютере "нарисую":

ХРАНИЛИЩЕ БИБЛИОТЕК:

. all_libs <----- где-то на компе, например прямо в C:\
|- lib_0 <----- клон репозитория
| |- include
| |- lib
| ...
|- lib1
| |- include
| |- lib
| ...
|
и.т.д

СТРУКТУРА ПРОЕКТА:

. my_project
|- config <----- конфигурация проекта с include-пасами на all_libs (%all_libs %, и.т.д)
|- main.cpp
... <----- 100500 файлов проекта

-------------------------------------------
По поводу тестов - всё аналогично коннекту либы с той разницей, что мы ещё дополнительно подключаем файлы, реализующие тесты, верно?

-------------------------------------------
"Копировать инклуды либы прямо в папку с инклудами проекта - довольно плохая идея"

А если через submodule добавлять?

-------------------------------------------
"ваша библиотека header-only или есть компилируемые файлы тоже?"

Компилируемые файлы есть. Один - чтобы избежать в одном месте проблемы взаимного использования классами друг друга. Но вообще то, что я сделал не особо как библиотеку рассматриваю. Отчасти потому, что у меня это часть проекта (грубо говоря, просто папочка), отчасти потому, что рассматриваю этот код именно как легковесную и априори небольшую надстроечку над классами С++.

=========================

Расскажу ещё на последок свою идею насчёт организации мини-проектов (например, для header-only или для микро-библиотек вроде той, что хочу выложить) с использованием submodule (подобный подход использую у себя в инфраструктуре для шареных не-библиотек между подпроектами):

РЕПОЗИТОРИИ:

sources_repo <- репозиторий исключительно с включаемыми "полезными" исходниками

lib_repo <- репозиторий
|- lib_sources <- папка с исходниками из sources_repo, подключена как подмодуль
|- doc <- документация
|- readme
|- LICENCE.txt
...и прочий мусор

РЕПОЗИТОРИЙ ДЛЯ ТЕСТА/ПРИМЕРА

example
|- lib_sources <- папка с исходниками из sources_repo, подключена как подмодуль
|- example.cpp
...и прочие файлы для работы примера

Примечание №1: Подход для теста/примера можно обобщить, пробросив ссылки на папку подмодуля через include-пасы в рамках репозитория со всеми примерами вместе
Примечание №2: Такой подход будет работать только если проект не требует сложно сборки, а когда в репе находится маленькая частичка кода - настолько маленькая, что не хочется париться с организацией её в виде полноценной библиотеки.

Как правильно организовать проект, выкладываемый в open source?

Большое спасибо за такой развёрнутый ответ! Это было полезно и познавательно!

Вообще ваш вопрос сильно связан с организацией процесса сборки библиотеки и её подключения к другим проектам

Вот да. В этом и дело. Когда я говорил про копи-пасту - я имел в виду не то, что я её руками делаю, а то, что происходит копирование данных вне системы контроля версий. А этом, в свою очередь, ломает историю (в данном случае говорю как папку include).

Вот это я не знаю честно говоря, зачем вы делаете - папки include и lib как раз на то и рассчитаны, чтобы их было удобно подключать к компилятору и линковщику

Дело в том, что, как я понял, git не поддерживает возможность привязки отдельных папок, даже через механизм подмодулей (только что проверял - не вышло через подмодули). А это значит, что папка include - если она в проект добавляется - будет лежать в проекте вместе со всем мусором... Но тут я могу что-то не так понимать - с гитом буквально месяц знаком. Подскажите, если ошибаюсь - буду благодарен.

Тесты вообще должны собираться вместе с библиотекой (например, в папку /bin), также по идее ничего никуда копировать не надо

А зачем? Тесты - штука побочная, почти служебная в рамках библиотеки, можно сказать. Чего замусоривать пользовательский билд служебные подобными штуками?

Также, вы почему-то не указали используемую систему сборки. В том же CMake есть очень полезная фишка, называется find_package, которую грех не использовать

Чем вы все-таки либу свою собираете? Это важно, т.к. даже для опытных разработчиков сборка незнакомой C++ библиотеки может стать целым делом

Да, я уже собирал assimp с cmake (первое моё знакомство с cmake) - чуть с ума не свихнулся пока сделал, день потратил на сборку. К счастью, как мне кажется, в рамках моей библиотечки вопрос сборки опускается по причине её миниатюрности. Фишка в том, что она - маленькая, но самостоятельная часть большего проекта: система регистрации классов для возможности их создания по строковым именам. Осознав, что её можно выделить в отдельный проект, понял что это хорошая возможность поучиться на ней как оформлять репоизтории и как дальше организовывать его контакт с реальным миром... В общем, думаю, для четырёх небольших исходников не имеет смысла сборку организовывать.

Как правильно организовать проект, выкладываемый в open source?

Ну, вот речь идёт как раз о том, чтобы было "просто использовать библиотеку в своём коде без дополнительных сложностей". Конечно, описанный мною алгоритм имеет своё обоснование - обновлять сорцы сторонней библиотеки в своём проекте нужно осторожно... Но почему бы не выделить "готовые" элементы библиотеки без шелухи отдельно от проекта и не использовать тот же механизм подмодулей для включения их в код желающих воспользоваться библиотекой... Ясно, там вопрос лицензирования может возникнуть - но лицензия прописывает и в исходниках тоже, насколько я знаю, этого достаточно.

Как лучше всего реализовывать property browser в QT?

Та я уже свой написал, без использования Model-View подхода.

Почему нельзя объявлять стековые объекты внешних классов для внутренних классов?

Ага... Теперь ясно. Спасибо за решение!

Почему нельзя объявлять стековые объекты внешних классов для внутренних классов?

AtomKrieg: аа... Блин, да. Ошибочка вышла в тестовом примере. Мне в основном коде не нужен объект внутреннего класса как поле. Он просто в рамках логики нужен. Спасибо что заметили. Сейчас поправлю вопрос.

Как выполнить действия до вызова функции main (header-only решение)?

shell_execute: спасибо за ссылки, но я похожее решение описал в рамках вопроса. Нашёл решение сам - выложу в ответе на вопрос.

Как выполнить действия до вызова функции main (header-only решение)?

Спасибо за ответ. Не знал про такую штуку, теперь буду знать. В рамках же моего вопроса - выглядит так, что это сильно платформозависимое решение. Для винды, пожалуй, подойдёт - но для прочих платформ вряд ли (если, конечно, на прочих платформах аналогичных вещей нету).

Как выполнить действия до вызова функции main (header-only решение)?

Sirikid: ура! Получилось. Я даже не понял почему... Вроде, просто ровно тот же тег заново перепрописал - и разметка сразу нормальной стала.

Как выполнить действия до вызова функции main (header-only решение)?

Sirikid: ха! Попробовал без изменений вставить текст вопроса в комментарий на хабру, глянул через предпросмотр - там всё в порядке. Видимо, движки для отображения разные.

Как выполнить действия до вызова функции main (header-only решение)?

Sirikid: я обернул - в тег cpp (вот такой: ) - но оно всё равно глючит, съедает табы. Это не первый раз когда у меня с тегом "code" для плюсов проблемы - на хабре регулярно парюсь с ним, особенно когда шаблоны появляются (они похожи на теги и потому глючат).

Попробую сейчас сделать как-то красивее (возможно, без тега лучше будет).