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

Цитата OpenGL @ 23.01.20, 07:30

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

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

Скрытый текст

Пока такие комплекты:

Цитата JoeUser @ 23.01.20, 01:49

Не не не - это тупик! Выводить битность из модели CPU - хреновое решение, имхо!
Представь, что выйдет какой-нить очередной камень, для его идентификации
потребуется свой макро, которого нет в том чудо списке - труба.

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

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

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

Если это единственная причина, ИМХО проще определить внешние источники, выставляемые в нужные буквы средствами сборки. Теми же makefile, например, передающие нужные строки макросами.

Типа как вот у меня. У меня, в слову, довольно примитивно, но работает.

CPU    = MPC5200
...
CPU    = MCF5485
...
CPU    = AM3505
...
!error Не задан целевой процессор
...
COMMON = ... -D$(CPU)
...
.cpp{$(OBJSDIR)}.obj::
        $(CL) $(OPTOPT) $(RTLOPT) $(DEBOPT) $(COMMON) -c -Fo$(OBJSDIR)\ $(COMPILE_XP) $<

Qraizer, задал мне задачку
Не, я что-то подобное сделал ... На этапе релизной сборки у меня первым этапом выполняется Perl-скрипт, который тупо находит в каталоге проекта файл Count.inc следующего содержания:

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

Парсит его, и увеличивает на единицу номер сборки.

Но как мне из текущего тулчейна выдрать мне необходимый сабж - пока ума не приложу.
Если искать его limits.h и парсить, так проще же его напрямую препроцессором пользовать?

Добавлено 23.01.20, 15:39

Цитата Qraizer @ 23.01.20, 15:13

передающие нужные строки макросами

Хотя ... в принципе да, можно при регистрации очередного тулчейна, произвести ему прописку D-флага, по типу -DBIT_NAME=x32
Пасип, навел на мысль! Если моя хрень будет где-то глючить, а я проверю, буду пользовать D-флаги.

Цитата JoeUser @ 23.01.20, 15:28

Пасип, навел на мысль!

Ну, когда ясна цельная цель, а не её фрагмент, советовать проще.
Просто первое, что пришло в голову – код-то кроссплатформенный, да, но средства разработки-то точно знают, под что они его собирают, вот пусть и поделятся этой инфой.

Цитата Qraizer @ 23.01.20, 15:52

Просто первое, что пришло в голову – код-то кроссплатформенный, да, но средства разработки-то точно знают, под что они его собирают, вот пусть и поделятся этой инфой.

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

Цитата Flex Ferrum @ 23.01.20, 16:06

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

Потому что, видимо, накладно при смене списка портов просматривать весь спагетти #if defined в поиске ошибок и неоднозначностей. К тому же в этих defined нет никакой единой системы, нужно тупо каждый раз лезть в доки и не дай бог пропустишь неочевидное, но важное условие. С другой стороны, независимость системы сборки – понятие относительное. К примеру, студийная консоль имеет отдельные скрипты, настраивающие окружение для сборки под конкретный таргет. А подобная интельная консоль таких скриптов имеет вообще вагон. И все они просто шпигуют окружение нужными переменными, которые достать из makefile не представляет ровным счётом никакой сложности. Смотрим любой POSIX и внезапно наблюдаем такую же картину, только там обычно скрипты CMake-овые или automake-овые. Вопрос "как же всё-таки проще" открыт.

Сообщение отредактировано: Qraizer - 23.01.20, 17:11

Flex Ferrum, Qraizer, вот в этом я ошибался:

Цитата JoeUser @ 23.01.20, 15:28

Если искать его limits.h и парсить, так проще же его напрямую препроцессором пользовать?

У всех тулчейнов стандартные заголовки - стандартны Да, есть различия во всяких приблудах типа tiff-conf.h и пр. Но это к стандартной либе отношения никакого не имеет.

Таким образом, запускаем и наблюдаем:

$ ./i686-w64-mingw32.static-gcc -v

Цитата

Using built-in specs.
COLLECT_GCC=./i686-w64-mingw32.static-gcc
COLLECT_LTO_WRAPPER=/home/majestio/Dev/cross/mxe/usr/libexec/gcc/i686-w64-mingw32.static/5.5.0/lto-wrapper
Target: i686-w64-mingw32.static
Configured with: /home/majestio/Dev/cross/mxe/tmp-gcc-i686-w64-mingw32.static/gcc-5.5.0/configure ac_cv_prog_HAVE_DOXYGEN=false --enable-doc=no --enable-gtk-doc=no --enable-gtk-doc-html=no --enable-gtk-doc-pdf=no --docdir=/home/majestio/Dev/cross/mxe/tmp-gcc-i686-w64-mingw32.static/gcc-5.5.0.build_.sink --infodir=/home/majestio/Dev/cross/mxe/tmp-gcc-i686-w64-mingw32.static/gcc-5.5.0.build_.sink --mandir=/home/majestio/Dev/cross/mxe/tmp-gcc-i686-w64-mingw32.static/gcc-5.5.0.build_.sink --with-html-dir=/home/majestio/Dev/cross/mxe/tmp-gcc-i686-w64-mingw32.static/gcc-5.5.0.build_.sink --disable-doxygen --target=i686-w64-mingw32.static --build=x86_64-pc-linux-gnu --prefix=/home/majestio/Dev/cross/mxe/usr --libdir=/home/majestio/Dev/cross/mxe/usr/lib --with-sysroot=/home/majestio/Dev/cross/mxe/usr/i686-w64-mingw32.static --enable-languages=c,c++,objc,fortran --enable-version-specific-runtime-libs --with-gcc --with-gnu-ld --with-gnu-as --disable-nls --disable-shared --disable-multilib --without-x --disable-win32-registry --enable-threads=posix --enable-sjlj-exceptions --enable-libgomp --with-gmp=/home/majestio/Dev/cross/mxe/usr/x86_64-pc-linux-gnu --with-isl=/home/majestio/Dev/cross/mxe/usr/x86_64-pc-linux-gnu --with-mpc=/home/majestio/Dev/cross/mxe/usr/x86_64-pc-linux-gnu --with-mpfr=/home/majestio/Dev/cross/mxe/usr/x86_64-pc-linux-gnu --with-as=/home/majestio/Dev/cross/mxe/usr/bin/i686-w64-mingw32.static-as --with-ld=/home/majestio/Dev/cross/mxe/usr/bin/i686-w64-mingw32.static-ld --with-nm=/home/majestio/Dev/cross/mxe/usr/bin/i686-w64-mingw32.static-nm
Thread model: posix
gcc version 5.5.0 (GCC)

Извлекаем:

$ ./i686-w64-mingw32.static-gcc -dumpspecs > ~/Dev/32.spec
$ ./x86_64-w64-mingw32.static-gcc -dumpspecs > ~/Dev/64.spec

Сравниваем:

Скрытый текст

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

Цитата Qraizer @ 23.01.20, 17:08

Потому что, видимо, накладно при смене списка портов просматривать весь спагетти #if defined в поиске ошибок и неоднозначностей.

Тут есть несколько моментов:
1) популярные фреймворки что-то такое уже содержат. Буст там, Qt и т. п. Можно переиспользовать.
2) Обычно это систематизируется и упрощается. Сначала - #ifdef'ы по типу компилятора, потом - включение файла, который содержит все необходимые детекты
3) Ну а что делать? Жизнь такая. В любом случае, компилятор знает, под какую платформу и архитектуру он компилирует код, и сообщает об этом.

Цитата JoeUser @ 23.01.20, 17:45

Пока они не ошибались.

Вот зараза!



Упссс, фикссс )))



Заголовок <cstdint> в QNX нужно использовать обязательно.

Сообщение отредактировано: JoeUser - 23.01.20, 21:36

Цитата Flex Ferrum @ 23.01.20, 18:38

1) популярные фреймворки что-то такое уже содержат. Буст там, Qt и т. п. Можно переиспользовать.

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

Цитата Qraizer @ 24.01.20, 12:57

Кстати, да.

Кстати нет Мы же не говорим о рантайме, мы говорим о собираемой цели.
Просто у меня нет пока тулчейнов для кросс-компиляции для Фряхи, QNX, Солярки и Андроида.
Поэтому пока приходится использовать их родные системы сборки. Для теста.
Хотя нет, вру Если я для себя пишу, то и они могли для меня написать.
Только вот да, где это все...

Сообщение отредактировано: JoeUser - 24.01.20, 16:35

Скрытый текст

Боже, какой сраный сейчас Солярис Извините меня за мой французский ...

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