В письме от 14 сентября 2017 22:36:27 пользователь Dmitry Belyavsky написал:
> > > > > > > Для 1.0.2 - drop-in replacement того, что в дистрибутиве. И с
> > > > > > > патчами.
> > > > > > Я правильно понимаю, что это надо описать как Legacy, и что в
> > > > > > будущем такого больше не будет...
> > > > > Это описано в версии для 1.0.2
> > > > Я наверное что-то пропустил... Где именно это описано?
> > > В README в ветке 1.0.2.
> > Ой, как все грустно...
> > Не знаю насколько глубоко мне тут следует влезать с моими улучшизмами, но
> > мне кажется, что тут что-то очень не хорошо со сруктурированием
> > информаци... Я бы этот README нашел бы только от отчаянья перебирая все
> > ветки подряд...
>
> Блин. Если ты работаешь с веткой 1.0.2, то там будет этот README, который
> для неё актуален.
> Для остальных это мёртвая история.
Для меня проблема в том, что, раз уж я начал ковыряться с документированием,
то это должно быть где-то описано словами. В смысле то что есть две ветки, для
1.1.0 и для 1.0.2, и в чем их разница. При этом это описание должно быть где-
то в корне (в смысле в том месте в которое человек заглянит в первую очередь).
README.md в мастере -- хорошее место для описания. Но я туда честно говоря
планировал отправить то что сейчас находится в README.gost переформатировав
под markdown и вынеся в отдельные файлы специфические подразделы.
И внутрь этого README.md описание ветвления уже как-то не лезет...
В идеальном мире я бы наверное хотел бы видеть engine живущий в одной ветке и
об #ifdef'ленный для работы с разными версиями OpenSSL'я. Как это сделано в
xmlsec. С единой документацией описывающей нюансы применения к разным версиям.
Но мир не совершенен.
Но все-таки хотелось бы организовать документирование так, чтобы начав читать
документацию с главной страницы (в данном случае это README.md), можно было бы
пройдя по ссылкам (не обязательно http, достаточно указания "читать там")
получить полную информацию о всем многообразии возможностей которое
предоставляет проект.
Это то чего мне хотелось бы получить в результате, способ получения немного
вторичен.
> Опиши текущее поведение
директория bin создается внутри дерева исходников
> и предлагаемое тобой.
директория bin создается внутри директории в которой была запущена сборка.
Остально можно оставить как есть.
> Поможет ссылка на best practice с сайта cmake, например.
Попробую. Я пока в другую сторону копаю. Но намек понял, галочку поставл.
А копаю я пока вот чего...
Посмотри пожалуйста мой кандидат в INSTALL.md, пока без pull'реквеста
https://github.com/dhyannataraj/engine/blob/ master/INSTALL.md
Он должен заменить CMake_ReadMe.md и я в него скопировал раздел CONFIGURATION
FILE из README.gost
Оный раздел я обмаркдаунил, но по тексту не редактировал, предполагая что есть
смысл это сделать отдельным коммитом...
Из README.gost этот раздел соответсвенно предполагается выкинуть...
Ну и еще, из собственно говоря раздела, я не очень понял по абзацу
BouncyCastle cryptoprovider has some problems with private key parsing from
PrivateKeyInfo,
so if you want to use old private key representation format, which supported
by BC,
you must add:
PK_PARAMS = LEGACY_PK_WRAP
to [gost_section]
О чем это, насколько это вообще еще актуально?
Кроме того у меня ощущение, что это на самом деле тянет на подраздел в разделе
configure, что-то типа CAVEATS, LEGACY или что-то подобное. Яснее будет, когда
я пойму статус этой информации. Потому что по-моему эта информация не нужна
95% пользователей, и я бы ее структурно вынес бы в отдельную единицу, чтобы
оные 95% могли бы ее проскипать не вникая глубоко...