Вопрос по лицензированию, GNU GPL v2 Опции

[Мусатов Констант...]

FreeRTOS распространяется по лицензии GNU General Public License (version 2).
Правильно ли я понимаю, что, если прошивка контроллера реализована с использованием FreeRTOS, то и на код программы, который не модифицирует исходный код ОС, а только использует его как библиотеку, все равно распространяется лицензия GNU GPLv2, что означает, что покупатель устройства с этим контроллером вправе запросить и получить полный исходный текст всей прошивки?
Так же, поскольку у контроллера есть дисплей, то прошивка обязана выводить лицензионную информацию: FreeRTOS и авторство, ссылка на лицензию или это не обязательно?
Последний вопрос, как внутри кода считать версию ОС, что бы не вписывать ее руками при обновлениях?

[AHTOXA]

У них не совсем GPL, у них с модификациями.
В общем, код можно не показывать.
Плюс к этому, нельзя сравнивать FreeRTOS с другими осями

[Мусатов Констант...]

У них не совсем GPL, у них с модификациями.
В общем, код можно не показывать.
Плюс к этому, нельзя сравнивать FreeRTOS с другими осями

Спасибо!
А на счет сравнивать. Как я понял сравнивать можно, но надо взять разрешение на публикацию, что бы они проверили корректность.

Да, а по поводу считывания из FreeRTOS ее версии?
И еще один вопрос. У многих тулчейнов есть возможность автоматического ведения номера билда - инкрементация при запуске. Я не нашел такого у IARа. Неужели нет?

[juvf]

И еще один вопрос. У многих тулчейнов есть возможность автоматического ведения номера билда - инкрементация при запуске. Я не нашел такого у IARа. Неужели нет?

я во всех тулчейнах прикручиваю макрос, который запускается перед/после сборки и в хидоре инкреметирует номер билд. Также в СИ есть макросы __DATE__ — дата компиляции;
__TIME__ — время компиляции, можно ими вместо номера билда пользоваться.

Было бы удобно, если такой функционал был бы встроен в тулчейн. В каких именно тулчейнах есть такой функционал? Пользуюсь разными, но ни в одном его не использую. Может он есть, а я не знаю.

[Мусатов Констант...]

я во всех тулчейнах прикручиваю макрос, который запускается перед/после сборки и в хидоре инкреметирует номер билд. Также в СИ есть макросы __DATE__ — дата компиляции;
__TIME__ — время компиляции, можно ими вместо номера билда пользоваться.

Было бы удобно, если такой функционал был бы встроен в тулчейн. В каких именно тулчейнах есть такой функционал? Пользуюсь разными, но ни в одном его не использую. Может он есть, а я не знаю.

Да, Дата у IAR есть, но они вместо цифрового кода, печатают строку в американском убогом формате.
В Микрософтовском я пользовался, еще были в других, но все это для больших машинок.

А какой смысл считать сборки? Когда вставляется номер ревизии (или какая-то подобная информация), то тут профит ясен - узнав номер ревизии, можно посмотреть по логу системы управления версиями, что реально прошито. А номер билда говорит только о количестве запусков тулчейна. Или тут что-то другое имеется в виду?

А затем, что когда собираешь, то забываешь перевести ручные счетчики. Путь номер билда идет бытрее релизов, это не страшно. Вон, номера билдов ОС у мелкомягких идут явно быстрее чем один в сутки.

[dxp]

А затем, что когда собираешь, то забываешь перевести ручные счетчики. Путь номер билда идет бытрее релизов, это не страшно. Вон, номера билдов ОС у мелкомягких идут явно быстрее чем один в сутки.

Вот я и интересуюсь, что за счётчики и зачем они нужны? Вот собрал я проект, например, получил номер 100, тут же собрал ещё раз, получил 101. Собрал ещё 10 раз, ничего не меняя, получил 111. Какая полезная информация в этом счётчике? Кому, чему и в какой ситуации это может помочь? Какая разница, сколько раз собрали, если 101 и 111 билды по содержанию ничем не отличаются?

[juvf]

Вот я и интересуюсь, что за счётчики и зачем они нужны? Вот собрал я проект, например, получил номер 100, тут же собрал ещё раз, получил 101. Собрал ещё 10 раз, ничего не меняя, получил 111. Какая полезная информация в этом счётчике? Кому, чему и в какой ситуации это может помочь? Какая разница, сколько раз собрали, если 101 и 111 билды по содержанию ничем не отличаются?

у меня номер билда обновляется только в релизной сборке. Профит такой: пользователь жалуется, что есть проблема... я её решил. на билде 101 проблемы нет (или на билде от 06.02.2017). отправил пользователю.... потом другой пользователь или тотже пользователь опять кричит - у меня проблема. Первый вопрос - назови билд или дату сборки. бывает так, что пользователь не обновил прогу.... бывает, что он обновил на десктопе, а на ноуте не обновил.... бывает, что другой пользователь не знает про обновление.... вобщем без билда я начинал искать в новом коде старую проблему..... а по номеру - я сразу понимал что он не обновился, вот проблема и не исчезла. причем такая ситуация часто возникает. бывает даже так, что отправил билд 101.... пользоыватель кричит - у меня проблема... выходит так, не то что он запустил не обновил билд 95 до 101, он вообще может откопать билд 75.... древний.. от куданить с флешки или с архива почты....
А по поводу номер ревизии и свн.... не всегда проект прикручен в системе контроля, когда к гиту, когда к свн-у... да и в гите или в меркуле номер ревизии такой вроде 734713bc047d87bf7eac9674765ae793478c50d3, а у пользователя такой d921970aadf03b3cf0e71becdaab3147ba71cdef. какой из них раньше? ещё есть ветки... как ревизия с разных веток будет приходить.... может какнить можно это приготовить и я его готовить не умею... у меня работает автобилд и дата сборки... этого более чем достаточно для моих задач.

[johnshadow]

да и в гите или в меркуле номер ревизии такой вроде 734713bc047d87bf7eac9674765ae793478c50d3, а у пользователя такой d921970aadf03b3cf0e71becdaab3147ba71cdef. какой из них раньше? ещё есть ветки... как ревизия с разных веток будет приходить.... может какнить можно это приготовить и я его готовить не умею...

У меня из git обычно забирается такой командной, которая выполняется автоматом перед компиляцией:

Код

git log --pretty=format:"(%ad %h)" --abbrev-commit --date=short -1

результат потом попадает в h-файл. Получается в итоге:

Код

#define GITHASH "(2017-02-03 db74878)"

в итоге и дату видно и не нужен длинючий hash. По дате можно определить "новизну" билда, а по hash найти конкретный коммит

Сообщение отредактировал johnshadow - Feb 6 2017, 07:33

[dxp]

У меня из git обычно забирается такой командной, которая выполняется автоматом перед компиляцией:

CODE

git log --pretty=format:"(%ad %h)" --abbrev-commit --date=short -1

результат потом попадает в h-файл. Получается в итоге:

CODE

#define GITHASH "(2017-02-03 db74878)"

в итоге и дату видно и не нужен длинючий hash. По дате можно определить "новизну" билда, а по hash найти конкретный коммит

+1. И совсем дело в командной или не командной разработке. Всё автоматизировано. Кроме того, если версия отдаётся в продакшн, то её (я про git) желательно пометить меткой, в этом случае можно использовать имя метки, которое можно сделать максимально осмысленным.