Структура открытых проектов

поделиться названиес стандарта

стандарта нету, общепринятая практика.

для этого используются какие-то тулзы

cmake/autotools

правильное постоение архитектуры проектов

как тебе удобнее так и правльно, у нас тут швабодка

Скорее всего такого нет. Только в крупных проектах вроде ядра, которое включает в себя подпроектики. Или IDE специфичное. Или вот. В общем в какой-то области максимум.

Общепринятого стандарта нет. Для каждого отдельного проекта - свой. Можешь посмотреть самые известные/долгоживущие, что-то общее у них точно будет.

makefile никто руками не пишет

Ещё как пишет, если проект небольшой. А так, есть moc от Qt, cmake, (прости, г-споди) autotools. Мануалы - в гугле.

Правильной архитектуры проектов тоже не бывает, для каждого проекта/команды она будет своя. Общие принципы примерно такие: исходники - отдельно, ресурсы - отдельно, директория для бинарников - отдельно и т.п; в корень - README, LICENSE и INSTALL.

Директории, как правило, именуются: src, res, bin и т.п. Файлы - как душе угодно (не считая вышеперечисленных, корневых: их принято именовать именно так, как указано).

Самый главный совет: удобство в использовании идёт впереди мифической правильности и идеологии.

Ещё очень хотелось бы почитать про правильное постоение архитектуры проектов: именование файлов, директорий и прочего.

гугло code convention, а так еще всякие «Совершенные коды», где авторы капитанят с миру по нитке бородатые правила хорошего тона. Про структурирование конкретно проектов была у какого-то чувака книжка, где он запрягал cmake, continuous integration и системы контроля версий. Там про красиво структурированные папочки тоже было. Вспомню название - отпишусь :)

UPD. Не уверен, что оно, но можешь попробовать например http://producingoss.com/producingoss.pdf

Самый главный совет: удобство в использовании идёт впереди мифической правильности и идеологии.

Неофит не всегда может понять, где хорошо, а где плохо.

Спасибо за разъяснение.

А где-нибудь есть сборка советов от этой практики?)

Спасибо за ссылочку

Спасибо!

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

Если там tl;dr, то вот короткий вариант для разгона http://stackoverflow.com/questions/8910457/structure-for-large-scale-c-projec...

Неофит не всегда может понять, где хорошо, а где плохо.

Зато может понять, с чем удобно работать, а с чем - нет. Это непринципиальные вопросы, доверяй внутренним ощущениям.

Не один новичок не поймет удобства vim, gentoo, git etc пока не испытает боли. Есть вещи которые требуют времени, прежде чем поймешь что к чему.

Ещё очень хотелось бы почитать про правильное постоение архитектуры проектов: именование файлов, директорий и прочего.

Именование файлов не имеет ничего общего с архитектурой проектов. Рекомендую пристально изучить FHS.

в общем случае я делаю так:

/
--include - инклуды отдельно
--src
--|--поддиректории по желанию
--share - всякая ресурсня
--lib - таскаемые за собой бинарники и исходники библиотек
--docs - если руки до доков доходят

систему сборки лучше используй cmake. Можно чистые makefile, autotools крайне не рекомендую, это трэш и содомия.

Gnu Coding Standards вроде как и содержимое проекта регламентирует, наличие README, Changelog и т.д.

что makefile никто руками не пишет, для этого используются какие-то тулзы. Где найти мануалы?

https://www.gnu.org/software/autoconf/manual/autoconf.html

https://www.gnu.org/software/automake/manual/automake.html

autotools крайне не рекомендую, это трэш и содомия.

не слушай его, autotools - это общепринятый стандарт, облегчающий портируемость на 100500 архитектур

этот общепринятый стандарт - говно. и в портировании на 100500 архитектур он скорее мешает.

этот общепринятый стандарт - говно

С каких это пор ты стал стандартом?

Так же я тут недавно узнал, что makefile никто руками не пишет

Почему, для совсем мелких проектов _без зависимостей_ можно и руками. В остальных случаях cmake, на autotools даже не смотри.

autotools - это общепринятый стандарт

Ни разу. Просто оно широко распространилось пока ему не было альтернатив. При наличии же cmake никто в здравом уме autocrap'ом пользоваться не будет.

облегчающий портируемость на 100500 архитектур

Дайте догадаюсь, вы нигде кроме x86 линукса autocrap'ом ничего не пробовали собирать.

GNU Hello

баттхёрт неосиляторов autotools ITT :)

Луговский тебя упаси от становления меня стандартом. Тебя заждались в биореакторе.

autotools крайне не рекомендую, это трэш и содомия.

не слушай его, autotools - это общепринятый стандарт, облегчающий портируемость на 100500 архитектур

Содомит детектед!

баттхёрт неосиляторов autotools ITT :)

К тому же еще и тролль.

makefile никто руками не пишет

4.2

Вот тут ещё вопррос подниму. Если я все картинки для своей приложухи на gtk кину в res, то как мне потом ссылаться на них в С коде? Ведь если я захочу собрать пакет потом, мне будет необходимо, что бы картинки vогли лежать в /usr/share , /usr/local/share , /opt etc

А так, есть moc от Qt

moc — это не система сборки, а препроцессор слотов с сигналами. Система сборки Qt — qmake.

для этого используются какие-то тулзы. Где найти мануалы?

да, вот, автотулз - отличный манулал. я после его прочтения всё вкурил сразу :)

http://markuskimius.wikidot.com/programming:tut:autotools

#define RESOURCE_ROOT, определённый в автогенерируемом на стадии конфигурации файле config.h?

как выглядит и как делат config.h ?

как выглядит

Зависит от вашего проекта. Обычно в нём просто много define'ов. Иногда этот файл не создаётся, и дефайны передаются как параметры командной строки компилятора, что-то вроде g++ -DRESOURCE_ROOT=\"/usr/share/\"

и как делат

От системы сборки зависит.

Системы нет. В общем понял, спасибо.