LINUX.ORG.RU

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

 , ,


0

3

Я заметил, что большинство открытых проетов используют опеределенный формат директорий. Например присутствие папки /src. Не могли бы вы поделиться названиес стандарта, или ссылкой на описание?
Так же я тут недавно узнал, что makefile никто руками не пишет, для этого используются какие-то тулзы. Где найти мануалы?
Ещё очень хотелось бы почитать про правильное постоение архитектуры проектов: именование файлов, директорий и прочего. Некоторые общие практики.
Спасибо за помощь!


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

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

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

cmake/autotools

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

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

x0r ★★★★★ ()

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

ziemin ★★ ()

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

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

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

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

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

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

schizoid ★★★ ()

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

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

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

slackwarrior ★★★★★ ()
Последнее исправление: slackwarrior (всего исправлений: 1)
Ответ на: комментарий от schizoid

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

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

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

actics ()
Ответ на: комментарий от actics

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

x0r ★★★★★ ()
Ответ на: комментарий от actics

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

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

schizoid ★★★ ()
Ответ на: комментарий от schizoid

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

actics ()

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

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

Manhunt ★★★★★ ()

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

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

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

Dark_SavanT ★★★★★ ()
Ответ на: комментарий от Dark_SavanT

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

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

Harald ★★★★★ ()

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

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

slovazap ★★★★★ ()
Ответ на: комментарий от Harald

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

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

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

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

slovazap ★★★★★ ()

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

Harald ★★★★★ ()
Ответ на: комментарий от anonymous

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

Dark_SavanT ★★★★★ ()
Ответ на: комментарий от Harald

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

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

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

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

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

Manhunt ★★★★★ ()
Последнее исправление: Manhunt (всего исправлений: 1)

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

4.2

LamerOk ★★★★★ ()

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

actics ()
Ответ на: комментарий от schizoid

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

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

dmfd ()
Ответ на: комментарий от actics

как выглядит

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

и как делат

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

dmfd ()
Последнее исправление: dmfd (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.