Определение целевой OS и разряднности препроцессором

Цитата JoeUser @ 26.01.20, 18:29

Осталось только на Андроиде проверить, но это потом

Довольно странный способ определения целевой ОС. Или я что то не понимаю? Почему не использовать команду uname ?

Сообщение отредактировано: Wound - 27.01.20, 07:28

Цитата Wound @ 27.01.20, 07:27

Или я что то не понимаю?

Ты видимо не с начала читал. Речь не идет определения ОС в рантайме, а в процессе сборки тулчейнами при кросс-компиляции. Ну а так как многих кросс-компиляторов под руками нет, приходится пользоваться нативными компиляторами.

Цитата JoeUser @ 27.01.20, 08:10

Ты видимо не с начала читал. Речь не идет определения ОС в рантайме, а в процессе сборки тулчейнами при кросс-компиляции. Ну а так как многих кросс-компиляторов под руками нет, приходится пользоваться нативными компиляторами.

А сборка у тебя не в рантайме проходит? И что значит кросс-компиляторы? Это когда ты из под винды даешь команду билдить под какую то определенную ОС? Ну так ключик подсунуть, не? Все равно не понимаю я. У тебя на скрине разве не рантайм информация, показанная красной стрелочкой?

Добавлено 27.01.20, 08:26
Я сколько не встречал компиляций, а под юниксы так тем более, обычно сначало выдирают через всякие команды нужные переменные окружения, а потом собирают используя эту инфу.
Например вот те же makefile's, выполняешь например какой то скрипт, или команду, получаешь данные, парсишь их, получаешь нужную тебе инфу, потом уже делаешь какие то вещи исходя из полученной инфы.

Добавлено 27.01.20, 08:35
Вот например что то подобное для кросс компиялции: https://vike.io/ru/573024/

Цитата Wound @ 27.01.20, 08:24

А сборка у тебя не в рантайме проходит?

Рантайм - это время исполнения программы. И по-скольку определение целевой ОС происходит во время сборки, да значит не в рантайме.

Цитата Wound @ 27.01.20, 08:24

И что значит кросс-компиляторы? Это когда ты из под винды даешь команду билдить под какую то определенную ОС?

Да именно так. Я из под линукса собираю версии для винды, в перспективе хотелось мы и для FreeBSD и МакОС.
См мое сообщение №16 (под спойлером там)

Цитата Wound @ 27.01.20, 08:24

Ну так ключик подсунуть, не?

Это было бы моим последним решением, мы уже с Qraizer'ом это обсуждали - пробежаться по всем установленным тулчейнам кросскомпиляции, и в каждом прописать через -D флаг. Но, кольу меня работает и без этого, зачем прописывать, если можно не прописывать

Цитата Wound @ 27.01.20, 08:24

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

Да, это стандартная процедура сборки прог под *nix
./configure
make
make install
На первом этапе как раз и собирается инфа для генерации мэйкфайла. Но это не мой случай.

Цитата JoeUser @ 27.01.20, 09:32

Рантайм - это время исполнения программы. И по-скольку определение целевой ОС происходит во время сборки, да значит не в рантайме.

А каким боком команда uname тогда к рантайму? Я же не предлагаю тебе ее вызывать внутри твоей программы Что тебе мешает во время сборки юзнуть команду uname, и определить целевую ОС?

Цитата JoeUser @ 27.01.20, 09:32

Это было бы моим последним решением, мы уже с Qraizer'ом это обсуждали - пробежаться по всем установленным тулчейнам кросскомпиляции, и в каждом прописать через -D флаг. Но, кольу меня работает и без этого, зачем прописывать, если можно не прописывать

Ну скажем так, если речь идет об исходном коде твоей программы, например вызов каких то системных функций/апи/итд. Тогда тут проще и правильнее все это делать макросами(хотя есть и другие варианты), как ты в первом посте написал.
Если речь идет о вызове каких то системных программ, и т.д. То тут используются как правило скрипты, makefiles, etc.

Например:

Цитата JoeUser @ 23.01.20, 08:14

Просто у меня стоит набор кросс-компиляторов, и я хочу в окно About разрабатываемой проги выводить дополнительно инфу о типе сборки. Наример "сборка для Windows x32", или "сборка для Linux x64", ну и т.д.

Вот это, как правило делается скриптом. Вот версию в программу ты как зашиваешь? В исходниках что ли ее генеришь? Или система сборки генерит номер версии, и передает его в виде переменной окружения, в исходник, в хидер файл, который затем уже компилится вместе с программой? Обычно, я сколько не встречал везде юзается второй вариант.

Сообщение отредактировано: Wound - 27.01.20, 09:58

Цитата Wound @ 27.01.20, 09:47

Что тебе мешает во время сборки юзнуть команду uname, и определить целевую ОС?

Я не получу целевую ОС, я получу ОС сборки. Для обычной компиляции и целевая ОС, и ОС сборки идентичны (вон как я под QNX и Solaris собирал). А вот для кросс-компиляции они разные. И если я юзану uname, то запустив под вендой в окошке About увижу "сборка для Linux-x64", что будет естественно неправдой.

Цитата Wound @ 27.01.20, 09:47

Вот версию в программу ты как зашиваешь? В исходниках что ли ее генеришь?

У меня есть файл, включенный в проект следующего содержания:

#if !defined(__GNUC__) && !defined(__attribute__)
#  define __attribute__(x) /*nothing*/
#endif
 
#define BUILD_NUMBER 9600
static __attribute__ ((unused)) const char* SIGNATURA = "|||||| = BUILD: 9600 = ||||||";

Если дебажу - он не изменяется. А вот в релизной сборке первым этапом выполняется Perl-скрипт:

#!/usr/bin/perl
 
$FileName = $ARGV[0];
if ($FileName) {
  # #define BUILD_NUMBER 4582
  # static char[] SIGNATURA = "|||||| = BUILD: 4582 = ||||||";
  open(F,"+<$FileName") || die "Shit happiness!";
  $L = join("",<F>);
  seek(F,0,0);
  $L = $1.($2+1).$3.($2+1).$5 if ($L =~ /(.+?BUILD_NUMBER\s+)(\d+)(.+?BUILD:\s+)(\d+)(.+)/s);
  print F $L;
  close(F);
  print "\nВерсия проекта обновлена успешно.\n\n";
}

Он в этом файле просто увеличивает номер на единицу, и только потом идет сборка.

Цитата JoeUser @ 27.01.20, 11:15

Я не получу целевую ОС, я получу ОС сборки. Для обычной компиляции и целевая ОС, и ОС сборки идентичны (вон как я под QNX и Solaris собирал). А вот для кросс-компиляции они разные. И если я юзану uname, то запустив под вендой в окошке About увижу "сборка для Linux-x64", что будет естественно неправдой.

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

Цитата JoeUser @ 27.01.20, 11:15

А вот в релизной сборке первым этапом выполняется Perl-скрипт:

Он у тебя файл под репозиторием меняет что ли? Обычно через переменную окружения делается же, или на крайняк создается файл с номером версии, который подключается хидером.

Сообщение отредактировано: Wound - 27.01.20, 12:01

Цитата Wound @ 27.01.20, 12:00

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

Я так и думал делать, если препроцессор не справился бы. Но он справился.

Цитата Wound @ 27.01.20, 12:00

или на крайняк создается файл с номером версии, который подключается хидером.

Так он и подключается хидером.

Цитата JoeUser @ 27.01.20, 13:26

Я так и думал делать, если препроцессор не справился бы. Но он справился.

ИМХО, это не по феншую, мягко говоря. Хотя я деталей не знаю.

Цитата JoeUser @ 27.01.20, 13:26

Так он и подключается хидером.

Ну я так понял, ты скриптом меняешь файл под репозиторием.

Цитата Wound @ 27.01.20, 15:13

ИМХО, это не по феншую, мягко говоря. Хотя я деталей не знаю.

У меня другое мнение. Все что можно сделать препроцессором, лучше делать им. А вот все уже, что не получается - внешним инструментарием. Ибо препроцессор - более "родное" средство для среды сборки, более универсальное, чем любой другой внешний инструментарий.

Цитата Wound @ 27.01.20, 15:13

Ну я так понял, ты скриптом меняешь файл под репозиторием.

Именно. Вот тут как раз "внешний инструмент" решает, в моем случае QtCreator не имеет средств хранения/управления версиями сборки. А вот эта "дополнительная" хрень:

static __attribute__ ((unused)) const char* SIGNATURA = "|||||| = BUILD: 9600 = ||||||";

нужна лишь для того, чтобы строка "|||||| = BUILD: 9600 = ||||||" находилась в результирующем исполняемом файле в явном и неискаженном виде. По этой "метке" мною была построена система обновлений проги на момент ее ввода в эксплуатацию. Приходилось латать разные мелочи , большей части, по оформлению. Эта хрень решала вопрос дистрибуции на 15 компов. Загрузчик сверял актуальную версию на сайте, и искал сигнатуру в исполняемом файле. Если видел разницу - обновлял весь установленный комплект. И только потом производил запуск... Кстати, тоже кроссплатформенно получилось

Цитата JoeUser @ 28.01.20, 05:26

У меня другое мнение. Все что можно сделать препроцессором, лучше делать им. А вот все уже, что не получается - внешним инструментарием. Ибо препроцессор - более "родное" средство для среды сборки, более универсальное, чем любой другой внешний инструментарий.

Ага, вот только проект не имеет отношения к среде сборки. Если ты разрабатываешь тулчейны компилятора, тогда вопросов нет. Но на сколько я понял, ты их используешь. И вот тут возникают вопросы, и очень большие. Вот в следующем релизе, разработчики убунты, соляриса, винды, и macOs поменяют имена своим макросам, и все у тебя поломается. Будешь заного создавать тему на форуме и материть на чем свет стоит разрабов

Цитата JoeUser @ 28.01.20, 05:26

нужна лишь для того, чтобы строка "|||||| = BUILD: 9600 = ||||||" находилась в результирующем исполняемом файле в явном и неискаженном виде. По этой "метке" мною была построена система обновлений проги на момент ее ввода в эксплуатацию. Приходилось латать разные мелочи , большей части, по оформлению. Эта хрень решала вопрос дистрибуции на 15 компов. Загрузчик сверял актуальную версию на сайте, и искал сигнатуру в исполняемом файле. Если видел разницу - обновлял весь установленный комплект. И только потом производил запуск... Кстати, тоже кроссплатформенно получилось

Можно было бы глянуть как это делают другие По идее там вообще не нужны никакие скрипты.

Сообщение отредактировано: Wound - 28.01.20, 07:29

Цитата Wound @ 28.01.20, 06:36

Вот в следующем релизе, разработчики убунты, соляриса, винды, и macOs поменяют имена своим макросам, и все у тебя поломается. Будешь заного создавать тему на форуме и материть на чем свет стоит разрабов

В никсах с 1985 г дефайны осей не менялись. Это кагбэ намекает
Ну а если добавится какая либо из новых осей, и она меня заинтересует - добавлю к себе и ее чек.

Цитата JoeUser @ 28.01.20, 05:26

Можно было бы глянуть как это делают другие По идее там вообще не нужны никакие скрипты.

Приведи пример для QtCreator'а и qmake ( или qbs), просто интересно.

Цитата JoeUser @ 28.01.20, 08:21

В никсах с 1985 г дефайны осей не менялись. Это кагбэ намекает
Ну а если добавится какая либо из новых осей, и она меня заинтересует - добавлю к себе и ее чек.

А это не важно, менялись они там или нет. Просто ты по сути нарушил принципы SOLID, и создал жесткую связь между тем, где связи нужно минимум.
Т.е. вместо DI, ты по сути зашил это в свой код. Я же и пишу, не по феншую это. Хотя работать оно наверное будет

Цитата JoeUser @ 28.01.20, 08:21

Приведи пример для QtCreator'а и qmake ( или qbs), просто интересно.

Ну для винды например как то так: https://stackoverflow.com/questions/4771470...ion-information

Цитата Wound @ 28.01.20, 08:37

Просто ты по сути нарушил принципы SOLID, и создал жесткую связь между тем, где связи нужно минимум.

Тут нужна именно жесткая связь, а точнее - однозначная. И вообще при чем тут процесс сборки и SOLID, последний к проектированию классов относится жи!

Цитата Wound @ 28.01.20, 08:37

Ну для винды например как то так: https://stackoverflow.com/questions/4771470...ion-information

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

Цитата JoeUser @ 28.01.20, 09:14

Тут нужна именно жесткая связь, а точнее - однозначная. И вообще при чем тут процесс сборки и SOLID, последний к проектированию классов относится жи!

Ну не только классов жи.

Цитата JoeUser @ 28.01.20, 09:14

Киля, у тебя есть желание поспорить, ради того чтобы поспорить?

Ты попросил привести ради интереса, я тебе привел. Что не так то?

Цитата JoeUser @ 28.01.20, 09:14

Ну в приведенной тобой ссылке также изменяются внешние ресурсы внешними утилитами.
Нахрена мне тоже самое, но по-другому? Какой я профит получу?

Ну я не знаю как тебе пояснить еще. Возможно ты просто с этим не сталкивался, и сделал как знаешь. Оно у тебя работает, и ты не понимаешь зачем тебе по другому.
Но выглядит это со стороны, как если бы врач гланды начал удалять через ...то самое.
Просто обычно делают как, например создают батник/скрипт сборки, в котором пишут что то типа:

$VERSION = "1.0"
$BUILD_NUMBER = "123"
$PRODUCT_VERSION = $VERSION + "." + $BUILD_NUMBER
 
...
qmake/cmake/makefile/etc trolololo

В итоге ты можешь легко управлять версиями, не замарачиваясь на то, где у тебя и что прописано в скриптах или еще где то. То что выше я написал - это даже может не под репой лежать, а задаваться прямо в системе сборки. Это логично, тут нет жесткой связи, этим легко управлять.

Цитата JoeUser @ 28.01.20, 09:14

Нахрена мне тоже самое, но по-другому? Какой я профит получу?

Ну вот какая разница - писать все в одной функции main, или разносить все по файлам/классам/функциям, нахрена козе баян и всякие эти функции/классы? Ведь все можно писать в одной функции main.
Я когда на паскале начинал программировать у меня именно так все и было. Никаких проблем не испытывал. Вот тут ответ будет ровно такой же как и на твой вопрос.

Сообщение отредактировано: Qraizer - 28.01.20, 12:05