Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[34.200.248.66] |
|
Сообщ.
#1
,
|
|
|
Всем привет!
Понадобилось для себя написать ряд условий препроцессора для определения, скажем так, "целей" для различных тулчейнов на базе CGG/Clang. Вот тут я определяю OS из списка: Windows, Linux, Mac OS X, FreeBSD, Android, Solaris, SunOS, QNX. Остальные операционные системы пока не интересуют. #if defined(_WIN32) || defined(_WIN64) || defined(__CYGWIN__) #define OS_NAME "Windows" #elif defined(__linux__) #define OS_NAME "Linux" #elif defined(__APPLE__) || defined(__MACH__) #define OS_NAME "Mac OS X" #elif defined(__FreeBSD__) #define OS_NAME "FreeBSD" #elif defined(__ANDROID__) #define OS_NAME "Android" #elif defined(sun) || defined(__sun) #if defined(__SVR4) || defined(__svr4__) #define OS_NAME "Solaris" #else #define OS_NAME "SunOS" #endif #elif defined(__QNX__) || defined(__QNXNTO__) #define OS_NAME "QNX" #else #error Unknown OS #endif Просьба проверить хотя бы поверхностно правильность. Самостоятельно мне чекать под все перечисленные OS нет возможности. Ну с миру по нитке, как говорится А вот с разрядностью нашел решение на SO: #if INTPTR_MAX == INT64_MAX #define BIT_NAME "x64" #else #define BIT_NAME "x32" #endif На сколько оно корректно? На сколько оно корректно для прочих архитектур, кроме i686 и x86_64. |
Сообщ.
#2
,
|
|
|
JoeUser
А зачем вы всё с ног на голову поставили? |
Сообщ.
#3
,
|
|
|
Цитата Pavia @ А зачем вы всё с ног на голову поставили? В смылсе? |
Сообщ.
#4
,
|
|
|
Цитата Pavia @ А зачем вы всё с ног на голову поставили? Так и не дождался объяснения вопроса! Скрытый текст |
Сообщ.
#5
,
|
|
|
1. В первой строке, наверное, опечатка, и должно быть в одном из вариантов _WIN64.
2. __OS2__ для OS/2 :-) Добавлено С разрядностью: 1. Похрамывает для случая 16-битных систем. 2. Itanium тоже (думается) должен совпасть с INTPTR_MAX == INT64_MAX, но он всё же не x64 (насколько я понимаю). |
Сообщ.
#6
,
|
|
|
Цитата Славян @ 1. В первой строке, наверное, опечатка, и должно быть в одном из вариантов _WIN64. Точно! Цитата Славян @ 2. __OS2__ для OS/2 :-) Эх ... такая система когда то была!!! Я с 3.62 версии ее юзать начинал. Лет 5 на ней сидел. Цитата Славян @ 1. Похрамывает для случая 16-битных систем. Не, не нужны они мне. Цитата Славян @ Itanium тоже (думается) должен совпасть с INTPTR_MAX == INT64_MAX, но он всё же не x64 (насколько я понимаю). Хм ... надо выяснить. Пасип, Славян! |
Сообщ.
#7
,
|
|
|
Лучше начать отсюда: https://sourceforge.net/p/predef/wiki/Home/
|
Сообщ.
#8
,
|
|
|
Flex Ferrum, по поводу OS - сверил, у меня все верно.
А вот по поводу: Цитата Славян @ 2. Itanium тоже (думается) должен совпасть с INTPTR_MAX == INT64_MAX, но он всё же не x64 (насколько я понимаю). Славян меня немного в тупик поставил. |
Сообщ.
#9
,
|
|
|
Цитата JoeUser @ А вот по поводу: Лучше смотреть на макросы из того же справочника. Размер int'а может не быть равным 64 да x64-платформах. Зависит от компилятора и флагов. |
Сообщ.
#10
,
|
|
|
Цитата Славян @ 2. Itanium тоже (думается) должен совпасть с INTPTR_MAX == INT64_MAX, но он всё же не x64 (насколько я понимаю). Если вики не врет: |
Сообщ.
#11
,
|
|
|
Цитата Flex Ferrum @ Лучше смотреть на макросы из того же справочника. Что-то там про разрядность не нахожу Цитата Flex Ferrum @ Размер int'а может не быть равным 64 да x64-платформах. Зависит от компилятора и флагов. А если вот так: #if (INTPTR_MAX == INT64_MAX) || defined(__LP64__) || defined(_LP64) #define BIT_NAME "x64" #else #define BIT_NAME "x32" #endif ??? |
Сообщ.
#12
,
|
|
|
Сообщ.
#13
,
|
|
|
Не не не - это тупик! Выводить битность из модели CPU - хреновое решение, имхо! Представь, что выйдет какой-нить очередной камень, для его идентификации потребуется свой макро, которого нет в том чудо списке - труба. Но всеж, думаю, последнее мое решение правильное - из заголовком используемого тулчейна! Добавлено Цитата Flex Ferrum @ Размер int'а может не быть равным 64 да x64-платформах. Стоп стоп стоп!!! Условие "INTPTR_MAX == INT64_MAX" говорит совсем о другом. А именно, что максимальный размер целого, могущего хранить указатель - равен предопределенной константе размера целого в 64 бита. Таким образом, может и __LP64__ тут лишняя проверка. |
Сообщ.
#14
,
|
|
|
Пример для проца AVR из stdint.h
Цитата Limits of integer types capable of holding object pointers #define INTPTR_MAX INT16_MAX #define INTPTR_MIN INT16_MIN #define UINTPTR_MAX UINT16_MAX |
Сообщ.
#15
,
|
|
|
У меня такое чувство, что ты решаешь компилятором задачу для системы сборки.
|
Сообщ.
#16
,
|
|
|
Цитата OpenGL @ У меня такое чувство, что ты решаешь компилятором задачу для системы сборки. Ну где-то так. Просто у меня стоит набор кросс-компиляторов, и я хочу в окно About разрабатываемой проги выводить дополнительно инфу о типе сборки. Наример "сборка для Windows x32", или "сборка для Linux x64", ну и т.д. Скрытый текст Пока такие комплекты: |
Сообщ.
#17
,
|
|
|
Цитата JoeUser @ Не не не - это тупик! Выводить битность из модели CPU - хреновое решение, имхо! Представь, что выйдет какой-нить очередной камень, для его идентификации потребуется свой макро, которого нет в том чудо списке - труба. Если камень выйдет такой, что у него будет принципиально отличная архитектура по битности - тебе в любом случае придётся в код лезть и править. Так что... Тут лучше без велосипедов. Поддержка множества платформ и архитектур - это геморрой. С этим надо просто смириться. |
Сообщ.
#18
,
|
|
|
Цитата JoeUser @ Если это единственная причина, ИМХО проще определить внешние источники, выставляемые в нужные буквы средствами сборки. Теми же makefile, например, передающие нужные строки макросами. Просто у меня стоит набор кросс-компиляторов, и я хочу в окно About разрабатываемой проги выводить дополнительно инфу о типе сборки. Наример "сборка для Windows x32", или "сборка для Linux x64", ну и т.д. |
Сообщ.
#19
,
|
|
|
Типа как вот у меня. У меня, в слову, довольно примитивно, но работает.
CPU = MPC5200 ... CPU = MCF5485 ... CPU = AM3505 ... !error Не задан целевой процессор ... COMMON = ... -D$(CPU) ... .cpp{$(OBJSDIR)}.obj:: $(CL) $(OPTOPT) $(RTLOPT) $(DEBOPT) $(COMMON) -c -Fo$(OBJSDIR)\ $(COMPILE_XP) $< |
Сообщ.
#20
,
|
|
|
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 и парсить, так проще же его напрямую препроцессором пользовать? Добавлено Цитата Qraizer @ передающие нужные строки макросами Хотя ... в принципе да, можно при регистрации очередного тулчейна, произвести ему прописку D-флага, по типу -DBIT_NAME=x32 Пасип, навел на мысль! Если моя хрень будет где-то глючить, а я проверю, буду пользовать D-флаги. |
Сообщ.
#21
,
|
|
|
Цитата JoeUser @ Ну, когда ясна цельная цель, а не её фрагмент, советовать проще.Пасип, навел на мысль! Просто первое, что пришло в голову – код-то кроссплатформенный, да, но средства разработки-то точно знают, под что они его собирают, вот пусть и поделятся этой инфой. |
Сообщ.
#22
,
|
|
|
Цитата Qraizer @ Просто первое, что пришло в голову – код-то кроссплатформенный, да, но средства разработки-то точно знают, под что они его собирают, вот пусть и поделятся этой инфой. Всю эту инфу можно вытащить из дефайнов компилятора. Только JoeUser почему-то не очень хочет. Но это единственный работающий способ, не зависящий при этом от системы сборки. |
Сообщ.
#23
,
|
|
|
Цитата Flex Ferrum @ Потому что, видимо, накладно при смене списка портов просматривать весь спагетти #if defined в поиске ошибок и неоднозначностей. К тому же в этих defined нет никакой единой системы, нужно тупо каждый раз лезть в доки и не дай бог пропустишь неочевидное, но важное условие. С другой стороны, независимость системы сборки – понятие относительное. К примеру, студийная консоль имеет отдельные скрипты, настраивающие окружение для сборки под конкретный таргет. А подобная интельная консоль таких скриптов имеет вообще вагон. И все они просто шпигуют окружение нужными переменными, которые достать из makefile не представляет ровным счётом никакой сложности. Смотрим любой POSIX и внезапно наблюдаем такую же картину, только там обычно скрипты CMake-овые или automake-овые. Вопрос "как же всё-таки проще" открыт. Всю эту инфу можно вытащить из дефайнов компилятора. Только JoeUser почему-то не очень хочет. Но это единственный работающий способ, не зависящий при этом от системы сборки. |
Сообщ.
#24
,
|
|
|
Flex Ferrum, Qraizer, вот в этом я ошибался:
Цитата JoeUser @ Если искать его 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-флаги юзать. |
Сообщ.
#25
,
|
|
|
Цитата Qraizer @ Потому что, видимо, накладно при смене списка портов просматривать весь спагетти #if defined в поиске ошибок и неоднозначностей. Тут есть несколько моментов: 1) популярные фреймворки что-то такое уже содержат. Буст там, Qt и т. п. Можно переиспользовать. 2) Обычно это систематизируется и упрощается. Сначала - #ifdef'ы по типу компилятора, потом - включение файла, который содержит все необходимые детекты 3) Ну а что делать? Жизнь такая. В любом случае, компилятор знает, под какую платформу и архитектуру он компилирует код, и сообщает об этом. |
Сообщ.
#26
,
|
|
|
Цитата JoeUser @ Пока они не ошибались. Вот зараза! Упссс, фикссс ))) Заголовок <cstdint> в QNX нужно использовать обязательно. |
Сообщ.
#27
,
|
|
|
Цитата Flex Ferrum @ Кстати, да. Если кроссплатформа на едином фреймворке, то какая-никакая единая система уже есть. Но не факт, что она хорошо документирована. 1) популярные фреймворки что-то такое уже содержат. Буст там, Qt и т. п. Можно переиспользовать. |
Сообщ.
#28
,
|
|
|
Цитата Qraizer @ Кстати, да. Просто у меня нет пока тулчейнов для кросс-компиляции для Фряхи, QNX, Солярки и Андроида. Поэтому пока приходится использовать их родные системы сборки. Для теста. Хотя нет, вру Если я для себя пишу, то и они могли для меня написать. Только вот да, где это все... |
Сообщ.
#29
,
|
|
|
Скрытый текст Боже, какой сраный сейчас Солярис Извините меня за мой французский ... |
Сообщ.
#30
,
|
|
|
Осталось только на Андроиде проверить, но это потом |
Сообщ.
#31
,
|
|
|
Цитата JoeUser @ Осталось только на Андроиде проверить, но это потом Довольно странный способ определения целевой ОС. Или я что то не понимаю? Почему не использовать команду uname ? |
Сообщ.
#32
,
|
|
|
Цитата Wound @ Или я что то не понимаю? Ты видимо не с начала читал. Речь не идет определения ОС в рантайме, а в процессе сборки тулчейнами при кросс-компиляции. Ну а так как многих кросс-компиляторов под руками нет, приходится пользоваться нативными компиляторами. |
Сообщ.
#33
,
|
|
|
Цитата JoeUser @ Ты видимо не с начала читал. Речь не идет определения ОС в рантайме, а в процессе сборки тулчейнами при кросс-компиляции. Ну а так как многих кросс-компиляторов под руками нет, приходится пользоваться нативными компиляторами. А сборка у тебя не в рантайме проходит? И что значит кросс-компиляторы? Это когда ты из под винды даешь команду билдить под какую то определенную ОС? Ну так ключик подсунуть, не? Все равно не понимаю я. У тебя на скрине разве не рантайм информация, показанная красной стрелочкой? Добавлено Я сколько не встречал компиляций, а под юниксы так тем более, обычно сначало выдирают через всякие команды нужные переменные окружения, а потом собирают используя эту инфу. Например вот те же makefile's, выполняешь например какой то скрипт, или команду, получаешь данные, парсишь их, получаешь нужную тебе инфу, потом уже делаешь какие то вещи исходя из полученной инфы. Добавлено Вот например что то подобное для кросс компиялции: https://vike.io/ru/573024/ |
Сообщ.
#34
,
|
|
|
Цитата Wound @ А сборка у тебя не в рантайме проходит? Рантайм - это время исполнения программы. И по-скольку определение целевой ОС происходит во время сборки, да значит не в рантайме. Цитата Wound @ И что значит кросс-компиляторы? Это когда ты из под винды даешь команду билдить под какую то определенную ОС? Да именно так. Я из под линукса собираю версии для винды, в перспективе хотелось мы и для FreeBSD и МакОС. См мое сообщение №16 (под спойлером там) Цитата Wound @ Ну так ключик подсунуть, не? Это было бы моим последним решением, мы уже с Qraizer'ом это обсуждали - пробежаться по всем установленным тулчейнам кросскомпиляции, и в каждом прописать через -D флаг. Но, кольу меня работает и без этого, зачем прописывать, если можно не прописывать Цитата Wound @ Я сколько не встречал компиляций, а под юниксы так тем более, обычно сначало выдирают через всякие команды нужные переменные окружения, а потом собирают используя эту инфу. Да, это стандартная процедура сборки прог под *nix ./configure make make install На первом этапе как раз и собирается инфа для генерации мэйкфайла. Но это не мой случай. |
Сообщ.
#35
,
|
|
|
Цитата JoeUser @ Рантайм - это время исполнения программы. И по-скольку определение целевой ОС происходит во время сборки, да значит не в рантайме. А каким боком команда uname тогда к рантайму? Я же не предлагаю тебе ее вызывать внутри твоей программы Что тебе мешает во время сборки юзнуть команду uname, и определить целевую ОС? Цитата JoeUser @ Это было бы моим последним решением, мы уже с Qraizer'ом это обсуждали - пробежаться по всем установленным тулчейнам кросскомпиляции, и в каждом прописать через -D флаг. Но, кольу меня работает и без этого, зачем прописывать, если можно не прописывать Ну скажем так, если речь идет об исходном коде твоей программы, например вызов каких то системных функций/апи/итд. Тогда тут проще и правильнее все это делать макросами(хотя есть и другие варианты), как ты в первом посте написал. Если речь идет о вызове каких то системных программ, и т.д. То тут используются как правило скрипты, makefiles, etc. Например: Цитата JoeUser @ Просто у меня стоит набор кросс-компиляторов, и я хочу в окно About разрабатываемой проги выводить дополнительно инфу о типе сборки. Наример "сборка для Windows x32", или "сборка для Linux x64", ну и т.д. Вот это, как правило делается скриптом. Вот версию в программу ты как зашиваешь? В исходниках что ли ее генеришь? Или система сборки генерит номер версии, и передает его в виде переменной окружения, в исходник, в хидер файл, который затем уже компилится вместе с программой? Обычно, я сколько не встречал везде юзается второй вариант. |
Сообщ.
#36
,
|
|
|
Цитата Wound @ Что тебе мешает во время сборки юзнуть команду uname, и определить целевую ОС? Я не получу целевую ОС, я получу ОС сборки. Для обычной компиляции и целевая ОС, и ОС сборки идентичны (вон как я под QNX и Solaris собирал). А вот для кросс-компиляции они разные. И если я юзану uname, то запустив под вендой в окошке About увижу "сборка для Linux-x64", что будет естественно неправдой. Цитата Wound @ Вот версию в программу ты как зашиваешь? В исходниках что ли ее генеришь? У меня есть файл, включенный в проект следующего содержания: #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"; } Он в этом файле просто увеличивает номер на единицу, и только потом идет сборка. |
Сообщ.
#37
,
|
|
|
Цитата JoeUser @ Я не получу целевую ОС, я получу ОС сборки. Для обычной компиляции и целевая ОС, и ОС сборки идентичны (вон как я под QNX и Solaris собирал). А вот для кросс-компиляции они разные. И если я юзану uname, то запустив под вендой в окошке About увижу "сборка для Linux-x64", что будет естественно неправдой. Ну тогда я бы наверное ключиком передавал бы. Ты же знаешь под что хочешь собрать исходники. Вот у меня есть проект, кросплатформенный, собирается и под виндой и под юниксом, так там просто выбираешь под что тебе нужно собрать, и собираешь, а в дженкинсе прописаны все ключи и настройки под разные системы. Цитата JoeUser @ А вот в релизной сборке первым этапом выполняется Perl-скрипт: Он у тебя файл под репозиторием меняет что ли? Обычно через переменную окружения делается же, или на крайняк создается файл с номером версии, который подключается хидером. |
Сообщ.
#38
,
|
|
|
Цитата Wound @ Ну тогда я бы наверное ключиком передавал бы. Ты же знаешь под что хочешь собрать исходники. Я так и думал делать, если препроцессор не справился бы. Но он справился. Цитата Wound @ или на крайняк создается файл с номером версии, который подключается хидером. Так он и подключается хидером. |
Сообщ.
#39
,
|
|
|
Цитата JoeUser @ Я так и думал делать, если препроцессор не справился бы. Но он справился. ИМХО, это не по феншую, мягко говоря. Хотя я деталей не знаю. Цитата JoeUser @ Так он и подключается хидером. Ну я так понял, ты скриптом меняешь файл под репозиторием. |
Сообщ.
#40
,
|
|
|
Цитата Wound @ ИМХО, это не по феншую, мягко говоря. Хотя я деталей не знаю. У меня другое мнение. Все что можно сделать препроцессором, лучше делать им. А вот все уже, что не получается - внешним инструментарием. Ибо препроцессор - более "родное" средство для среды сборки, более универсальное, чем любой другой внешний инструментарий. Цитата Wound @ Ну я так понял, ты скриптом меняешь файл под репозиторием. Именно. Вот тут как раз "внешний инструмент" решает, в моем случае QtCreator не имеет средств хранения/управления версиями сборки. А вот эта "дополнительная" хрень: static __attribute__ ((unused)) const char* SIGNATURA = "|||||| = BUILD: 9600 = ||||||"; нужна лишь для того, чтобы строка "|||||| = BUILD: 9600 = ||||||" находилась в результирующем исполняемом файле в явном и неискаженном виде. По этой "метке" мною была построена система обновлений проги на момент ее ввода в эксплуатацию. Приходилось латать разные мелочи , большей части, по оформлению. Эта хрень решала вопрос дистрибуции на 15 компов. Загрузчик сверял актуальную версию на сайте, и искал сигнатуру в исполняемом файле. Если видел разницу - обновлял весь установленный комплект. И только потом производил запуск... Кстати, тоже кроссплатформенно получилось |
Сообщ.
#41
,
|
|
|
Цитата JoeUser @ У меня другое мнение. Все что можно сделать препроцессором, лучше делать им. А вот все уже, что не получается - внешним инструментарием. Ибо препроцессор - более "родное" средство для среды сборки, более универсальное, чем любой другой внешний инструментарий. Ага, вот только проект не имеет отношения к среде сборки. Если ты разрабатываешь тулчейны компилятора, тогда вопросов нет. Но на сколько я понял, ты их используешь. И вот тут возникают вопросы, и очень большие. Вот в следующем релизе, разработчики убунты, соляриса, винды, и macOs поменяют имена своим макросам, и все у тебя поломается. Будешь заного создавать тему на форуме и материть на чем свет стоит разрабов Цитата JoeUser @ нужна лишь для того, чтобы строка "|||||| = BUILD: 9600 = ||||||" находилась в результирующем исполняемом файле в явном и неискаженном виде. По этой "метке" мною была построена система обновлений проги на момент ее ввода в эксплуатацию. Приходилось латать разные мелочи , большей части, по оформлению. Эта хрень решала вопрос дистрибуции на 15 компов. Загрузчик сверял актуальную версию на сайте, и искал сигнатуру в исполняемом файле. Если видел разницу - обновлял весь установленный комплект. И только потом производил запуск... Кстати, тоже кроссплатформенно получилось Можно было бы глянуть как это делают другие По идее там вообще не нужны никакие скрипты. |
Сообщ.
#42
,
|
|
|
Цитата Wound @ Вот в следующем релизе, разработчики убунты, соляриса, винды, и macOs поменяют имена своим макросам, и все у тебя поломается. Будешь заного создавать тему на форуме и материть на чем свет стоит разрабов В никсах с 1985 г дефайны осей не менялись. Это кагбэ намекает Ну а если добавится какая либо из новых осей, и она меня заинтересует - добавлю к себе и ее чек. Цитата JoeUser @ Можно было бы глянуть как это делают другие По идее там вообще не нужны никакие скрипты. Приведи пример для QtCreator'а и qmake ( или qbs), просто интересно. |
Сообщ.
#43
,
|
|
|
Цитата JoeUser @ В никсах с 1985 г дефайны осей не менялись. Это кагбэ намекает Ну а если добавится какая либо из новых осей, и она меня заинтересует - добавлю к себе и ее чек. А это не важно, менялись они там или нет. Просто ты по сути нарушил принципы SOLID, и создал жесткую связь между тем, где связи нужно минимум. Т.е. вместо DI, ты по сути зашил это в свой код. Я же и пишу, не по феншую это. Хотя работать оно наверное будет Цитата JoeUser @ Приведи пример для QtCreator'а и qmake ( или qbs), просто интересно. Ну для винды например как то так: https://stackoverflow.com/questions/4771470...ion-information |
Сообщ.
#44
,
|
|
|
Цитата Wound @ Просто ты по сути нарушил принципы SOLID, и создал жесткую связь между тем, где связи нужно минимум. Тут нужна именно жесткая связь, а точнее - однозначная. И вообще при чем тут процесс сборки и SOLID, последний к проектированию классов относится жи! Цитата Wound @ Ну для винды например как то так: https://stackoverflow.com/questions/4771470...ion-information Киля, у тебя есть желание поспорить, ради того чтобы поспорить? Ну в приведенной тобой ссылке также изменяются внешние ресурсы внешними утилитами. Нахрена мне тоже самое, но по-другому? Какой я профит получу? |
Сообщ.
#45
,
|
|
|
Цитата JoeUser @ Тут нужна именно жесткая связь, а точнее - однозначная. И вообще при чем тут процесс сборки и SOLID, последний к проектированию классов относится жи! Ну не только классов жи. Цитата JoeUser @ Киля, у тебя есть желание поспорить, ради того чтобы поспорить? Ты попросил привести ради интереса, я тебе привел. Что не так то? Цитата JoeUser @ Ну в приведенной тобой ссылке также изменяются внешние ресурсы внешними утилитами. Нахрена мне тоже самое, но по-другому? Какой я профит получу? Ну я не знаю как тебе пояснить еще. Возможно ты просто с этим не сталкивался, и сделал как знаешь. Оно у тебя работает, и ты не понимаешь зачем тебе по другому. Но выглядит это со стороны, как если бы врач гланды начал удалять через ...то самое. Просто обычно делают как, например создают батник/скрипт сборки, в котором пишут что то типа: $VERSION = "1.0" $BUILD_NUMBER = "123" $PRODUCT_VERSION = $VERSION + "." + $BUILD_NUMBER ... qmake/cmake/makefile/etc trolololo В итоге ты можешь легко управлять версиями, не замарачиваясь на то, где у тебя и что прописано в скриптах или еще где то. То что выше я написал - это даже может не под репой лежать, а задаваться прямо в системе сборки. Это логично, тут нет жесткой связи, этим легко управлять. Цитата JoeUser @ Нахрена мне тоже самое, но по-другому? Какой я профит получу? Ну вот какая разница - писать все в одной функции main, или разносить все по файлам/классам/функциям, нахрена козе баян и всякие эти функции/классы? Ведь все можно писать в одной функции main. Я когда на паскале начинал программировать у меня именно так все и было. Никаких проблем не испытывал. Вот тут ответ будет ровно такой же как и на твой вопрос. |
Сообщ.
#46
,
|
|
|
Цитата Wound @ Ты попросил привести ради интереса, я тебе привел. Что не так то? Я думал что это что-то принципиально иное. А так - просто альтернатива. Она мне не нужна, ибо мой механизм с момента написания (2012 год) работает как часики. Цитата Wound @ Ну вот какая разница - писать все в одной функции main Для этого у меня отдельный файл-инклюд. Который решает ровно то, что должен решать. И ничего иного. Что не так? Цитата Wound @ Просто обычно делают как, например создают батник/скрипт сборки, в котором пишут что то типа: Так и у меня тоже самое, но не для ручной правки. У это меня автоматизировано. К примеру, работаю на нативном тулчейне - оно мне "Linux" прописывает. Выбрал активным другой тулчейн, к примеру x86_64-w64-mingw32.shared - оно мне "Windows" прописывает. И вообще заморачиваться не надо! Это уже давно за меня разработчики GCC/Clang решили (объявив соответствующие дефайны). |
Сообщ.
#47
,
|
|
|
Цитата JoeUser @ Так и у меня тоже самое, но не для ручной правки. У это меня автоматизировано. К примеру, работаю на нативном тулчейне - оно мне "Linux" прописывает. Выбрал активным другой тулчейн, к примеру x86_64-w64-mingw32.shared - оно мне "Windows" прописывает. И вообще заморачиваться не надо! Это уже давно за меня разработчики GCC/Clang решили (объявив соответствующие дефайны). Куда прописывает? И о какой ручной правке речь идет? Я лично вижу два варианта для прокидывания версии: 1) Просто тупо передавать ее извне - как описывал я. 2) Зашить ее где то в исходнике в виде баяна, потом написать скрипт, который будет парсить этот исходник вычленяя баян, и писать версию, не пойми откуда взятую(или прокинутую из вне или сгенерированную самим же скриптом) в этот файл. Я тебе пишу, обычно используют первый вариант. Он тупо проще. Ты мне пишешь - нахрена мне альтернатива, у меня с 2012 года все работает. Ну ок, работает, и работает. Мне совершенно коллинеарно, как оно у тебя там работает. |
Сообщ.
#48
,
|
|
|
Цитата JoeUser @ Здорово, когда кодировки совпадают. Я бы сделал параметр командной строки типа -what_is_you_ver и пусть исполняемый файл сам циферки выведет в stdout Загрузчик сверял актуальную версию на сайте, и искал сигнатуру в исполняемом файле. |
Сообщ.
#49
,
|
|
|
Цитата Qraizer @ Здорово, когда кодировки совпадают. Ну да, в проге я использовал UTF-8. А согласно определению: Цитата UTF-8 — представление Юникода, обеспечивающее наилучшую совместимость со старыми системами, использовавшими 8-битные символы. Текст, состоящий только из символов с номером меньше 128, при записи в UTF-8 превращается в обычный текст ASCII. И наоборот, в тексте UTF-8 любой байт со значением меньше 128 изображает символ ASCII с тем же кодом. Остальные символы Юникода изображаются последовательностями длиной от двух до шести байт (на деле, только до четырех байт, поскольку в Юникоде нет символов с кодом больше 10FFFF16, и вводить их в будущем не планируется), в которых первый байт всегда имеет вид 11xxxxxx, а остальные — 10xxxxxx. моя "сигнатура" состоит из однобайтовых символов. Поэтому тут все норм. Цитата Qraizer @ Я бы сделал параметр командной строки типа -what_is_you_ver и пусть исполняемый файл сам циферки выведет в stdout Да, как вариант. Но я уже поступил по-другому. Считаю, что это непринципиально. |
Сообщ.
#50
,
|
|
|
Цитата JoeUser @ Было бы интересно посмотреть работу твоей программы в OS/360. Особенно тебе самому. Много нового о кодировках узнал бы.Ну да, в проге я использовал UTF-8. В цитате, кстати, ерунда написана. Могли бы не лениться, а прямо написать, что первый байт имеет вид 1…10X…X, и количество ведущих единиц равно длине кода символа. А так как в цитате, уже трёхбайтовые символы (иероглифы китайские, например) будут кодироваться неправильно. Первым неправильно кодируемым будет '\u1000'. |
Сообщ.
#51
,
|
|
|
Цитата amk @ Было бы интересно посмотреть работу твоей программы в OS/360. Особенно тебе самому. Много нового о кодировках узнал бы. Вообще то под эту "некромантию" не планировалось ... ну да ладно. А с ней что не так? Считал содержимое исполняемого файла в символьный массив, нашел сигнатуру, и ... что не так? Или там читают справа на лево? Цитата amk @ В цитате, кстати, ерунда написана. Могли бы не лениться, а прямо написать, что первый байт имеет вид 1…10X…X, и количество ведущих единиц равно длине кода символа. А так как в цитате, уже трёхбайтовые символы (иероглифы китайские, например) будут кодироваться неправильно. Первым неправильно кодируемым будет '\u1000'. Это цитата из вики. Если считаешь, что там написали хрень - могу дать ссылку. Зайдешь и напишешь правильно. Ссылку дать? |
Сообщ.
#52
,
|
|
|
Цитата JoeUser @ Если ты программу, которая будет искать сигнатуру скомпилируешь там же в OS/360, то скорее сего всё будет работать, а вот если будешь делать проверку удалённо (эти старички и в сети могут работать), то никакой сигнатуры ты в исполняемом файле не найдёшь. В OS/360 используется кодировка EBCDIC, а кодировка ASCII используется только как внешняя, текстовые файлы в ней надо перекодировать при чтении/записи. Считал содержимое исполняемого файла в символьный массив, нашел сигнатуру, и ... что не так? Добавлено Цитата JoeUser @ Не надо. На вики как раз правильно написано, а не так как в твоей цитате.Это цитата из вики. Если считаешь, что там написали хрень - могу дать ссылку. Зайдешь и напишешь правильно. Ссылку дать? Может тебе вместо вики какой-то левый сайт с неправильными определениями подсовывают? |
Сообщ.
#53
,
|
|
|
Цитата amk @ Может тебе вместо вики какой-то левый сайт с неправильными определениями подсовывают? Честно говоря забыл откуда брал цитату. По поиску выходит какая-то книга. Но брал точно не оттуда. |