[Darth Vader 0]

Состав и структура проекта задается в панели дерева проекта - там перечень файлов, подлежащих компиляции. В опциях проекта есть опции компиляции, пути поиска включаемых файлов, путь к линкер-скрипту и пр. По идее, всё это является исходными данными для создания мейкфайла.

Но не могу нигде найти его в папке проекта, как и саму утилиту make внутри папки с установленной IDE. Кто разбирался с этим, подскажите, где их искать? 

Или ничего этого в Кейле раздельно не существует, и мейкфайл формируется внутри файла проекта, а функцию утилиты make выполняет сам исполняемый файл IDE?

[Forger 17]

51 minutes ago, Darth Vader said:

Кто разбирался с этим, подскажите, где их искать? 

А зачем некой платной IDE формировать make файл? Смысл?

[Darth Vader 0]

2 часа назад, Forger сказал:

А зачем некой платной IDE формировать make файл? Смысл?

Это зависит от построения самой IDE.

Можно формировать файл сценария сборки и запускать make или любой его аналог. А можно весь сценарий сборки держать в файле проекта, и при сборке сама IDE будет отрабатывать этот сценарий, запуская компилятор и линкер с нужными параметрами.

Видимо, в Кейле реализован второй вариант.

[Forger 17]

2 hours ago, Darth Vader said:

Видимо, в Кейле реализован второй вариант.

Keil позволяет создать make файл: https://developer.arm.com/documentation/ka004586/latest

Вопрос в другом - зачем вообще кому-то сборку делать ВНЕ среды? Я серьезно.

Ведь компилятор-то все равно платный. А 6-й компилятор так вообще не получится запустить вне keil (речь про леченную версию среды).

 

Если же дрюкаться с бесплатным GCC, то зачем вообще тогда keil - есть более удобные среды под gcc.

Например, у тех же ST есть своя среда на базе eclipse+gcc.

[Darth Vader 0]

2 часа назад, Forger сказал:

зачем вообще кому-то сборку делать ВНЕ среды? Я серьезно.

Организации, производящей сертификацию ПО вся IDE не нужна. Им нужна инструкция по сборке прошивки из исходников. В идеале, запустили один батник -  на выходе получили HEX или BIN - сравнили результат с тем, что в КД на инвентарном учете. Совпало - хорошо, работаем дальше. Нет - до-свиданья, ваша учтенная КД противоречит сама себе: из исходников собирается не то.

Всю IDE им посылать нельзя - без ключа она не работает. А наш ключ мы им послать не можем. Юридически, им пользоваться можем только мы, и передавать его третьим лицам не имеем права. Не кейген же им посылать с инструкцией по кряку Кейла  

Вот я и прорабатываю вариант, как выдрать из IDE только компилятор и утилиту типа make, а из проекта мейкфайл, чтобы отработать сборку ПО без IDE. Но, похоже, с Кейлом это не прокатывает.

2 часа назад, Forger сказал:

А 6-й компилятор так вообще не получится запустить вне keil

А как же его тогда запускать в иных IDE, типа Eclipse, VScode, QTCreator? Да и просто, безо всяких IDE? Надо мне вот скомпилировать один файл, создаю батник, где вызываю компилятор с нужными мне параметрами. Что ему ещё нужно, чтобы он работал? Лицензионный ключ в параметрах передать?

[SII 0]

Компилятор нормально запускается и из командной строки (собственно, из неё он и запускается, просто среда это благополучно маскирует). Вопрос, правда, в том, будет ли он работать без лицензии.

[Forger 17]

2 hours ago, Darth Vader said:

Организации, производящей сертификацию ПО вся IDE не нужна. 

Ага, чисто по-русски: и на сосну залезть и зад не ободрать.

Нужна сборка из сырцов - платим за лицензию компилятора. У ARM компилятор ПЛАТНЫЙ. Среда тоже. Но подтягивая компилятор, он проверяет наличие действующей лиценции KEIL. По крайней мере 6-й, а не античный 5-й.

Пишите под GCC проект. Он бесплатный.

Кстати, 6-й компилятор построен максимально совместимым с GCC.

 

1 hour ago, SII said:

Компилятор нормально запускается и из командной строки

Без установки среды и ключа к ней он не запустится. Можете скачать отдельно и проверить лично: https://developer.arm.com/tools-and-software/embedded/arm-compiler/downloads/version-6

 

2 hours ago, Darth Vader said:

А как же его тогда запускать в иных IDE, типа Eclipse, VScode, QTCreator? Да и просто, безо всяких IDE?

Очевидно, что нужно за него заплатить. Повторюсь, ARM-компилятор ПЛАТНЫЙ

[one_eight_seven 3]

5 hours ago, Forger said:

Вопрос в другом - зачем вообще кому-то сборку делать ВНЕ среды? Я серьезно.

Автоматическое тестирование. Ну это про "вообще" и про "кому-то", а не конкретно про случай автора.

[Darth Vader 0]

45 минут назад, Forger сказал:

Повторюсь, ARM-компилятор ПЛАТНЫЙ

Это понятно. Не понятно КАК компилятор определяет: заплатили за него или нет? Я вижу 2 возможных варианта:

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

2. Есть лишь одна единая версия компилятора - платная полнофункциональная. Но ей требуется валидный файл ключа в его каталоге. Либо, ключ ему надо передавать в качестве одного из параметров каждый раз при запуске.

[Forger 17]

14 minutes ago, Darth Vader said:

 Не понятно КАК компилятор определяет: заплатили за него или нет? 

Не важно как. Есть GCC - подкорректируйте проект под него и тогда не будет вопросов с сертификацией или что там у вас

1 hour ago, one_eight_seven said:

Автоматическое тестирование.

купить лицензию тестировщикам, это ж не проблема для серьезной организации ))

[Darth Vader 0]

7 минут назад, Forger сказал:

Есть GCC - подкорректируйте проект под него и тогда не будет вопросов

Нельзя. Проект такой как есть. Разработка завершена, КД утверждена. Осталась сертификация. Надо, чтобы в компетентных органах проект собрался один в один из учтённых исходников в тот самый hex-файл, что лежит на инвентарном учете. А для этого нужен именно тот самый компилятор, которым собирался проект, а не какой-то другой.

[Gorby 6]

1 hour ago, Darth Vader said:

Нельзя. Проект такой как есть. Разработка завершена, КД утверждена. Осталась сертификация. Надо, чтобы в компетентных органах проект собрался один в один из учтённых исходников в тот самый hex-файл, что лежит на инвентарном учете. А для этого нужен именно тот самый компилятор, которым собирался проект, а не какой-то другой.

Так не получится. Хекс файл собирается из объектных модулей, в которые при компиляции попадает много Левой информации — пути к файлам, дата компиляции и много чего ещё. Так что не факт, что собранный на другом компе хекс  бит в бит совпадёт с оригинальным, даже если исходный код не менялся и исполняемый код в принципе один и тот же. 

[Forger 17]

1 hour ago, Gorby said:

 Так что не факт, что собранный на другом компе хекс  бит в бит совпадёт с оригинальным, даже если исходный код не менялся и исполняемый код в принципе один и тот же. 

Как раз факт что все совпадет, если среда/компилятор/линкер дырка-в-дырку как на основной машине. А пути и другая левая инфа в прошивку не попадает, кроме случая, если это заложено в самом коде проекта.

 

3 hours ago, Darth Vader said:

Надо, чтобы в компетентных органах проект собрался один в один из учтённых исходников в тот самый hex-файл,

Отдать им под расписку ноутбук где все собиралось. Ноутбук может быть убогий. Это не критично.

[Arlleex 131]

9 часов назад, Forger сказал:

А пути и другая левая инфа в прошивку не попадает, кроме случая, если это заложено в самом коде проекта.

У меня во всех проектах, например, автоматом во Flash размещается 32-битный маркер, содержащий дату сборки проекта.
Реже, бывает, добавляю еще один с временем сборки. Использую для внутренних нужд, либо (было и такое) по требованию ТЗ.

Ну и? За каким таким этаким "компетентным органам" нужна компиляция бит-в-бит?

@Darth Vader, а как Вы вообще планировали проходить сертификацию, разрабатывая на коммерческом платном ПО?

[makc 190]

4 минуты назад, Arlleex сказал:

Ну и? За каким таким этаким "компетентным органам" нужна компиляция бит-в-бит?

Например, ФСБ. Но не только им. В принципе при любой сертификации на соответствие требованиям информационной безопасности будут требовать совпадения результатов сборки с эталоном, предоставленным разработчиком или объяснить почему именно наблюдаются несовпадения. Поэтому зачастую проще добиться совпадения с точностью до бита, чем потом писать развернутое произведение о том, как там устроен компилятор и система сборки.

7 минут назад, Arlleex сказал:

@Darth Vader, а как Вы вообще планировали проходить сертификацию, разрабатывая на коммерческом платном ПО?

Это ни коим образом не мешает сертификации, если только речь не идёт о сертификации самого компилятора или среды разработки. ;-)

PS: Проблема повторяемости результатов сборки стоит не только у компетентных органов, но и открытые проекты тоже озабочены этим вопросом - https://wiki.debian.org/ReproducibleBuilds

9 часов назад, Forger сказал:

Отдать им под расписку ноутбук где все собиралось. Ноутбук может быть убогий. Это не критично.

Намного проще отдать образ виртуальной машины, как эталон среды сборки проекта.

10 часов назад, Gorby сказал:

Так не получится. Хекс файл собирается из объектных модулей, в которые при компиляции попадает много Левой информации — пути к файлам, дата компиляции и много чего ещё. Так что не факт, что собранный на другом компе хекс  бит в бит совпадёт с оригинальным, даже если исходный код не менялся и исполняемый код в принципе один и тот же. 

Позвольте с Вами не согласиться. Обычно отладочная информация (включая пути к исходникам) попадает не в bin/hex, а в elf/obj и т.п. Если эта информация попадает в загрузочные файлы прошивки, то скорее всего её туда сознательно добавил разработчик с помощью определенных своих действий и поэтому у него есть возможность избавиться от подобной лишней информации в файле. Могу утверждать по собственному опыту, что я неоднократно добивался сборки ПО на разных машинах с совпадением результатов байт в байт, естественно при совпадении сборочного окружения и средств разработки.