Как из питона увидеть флаги -D (дефайны) с которыми была собрана импортируемая библиотека?

https://stackoverflow.com/questions/10192758/how-to-get-the-list-of-options-that-python-was-compiled-with

Это не подходит?

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

Насколько я понял, это опции сборки самого питона. А мне нужны опции сборки моего модуля

Я пишу на сях функцию, компилирую ее в shared или dll библиотеку с именем mymodule а потом пишу в питоне

import mymodule

и мне интересно узнать после этого в питоне с какими -D был собран mymodule

Никак. Дефайны существуют только при препроцессинге

строку с параметрами компилятора вкомпилить же, ну

Никак.

Это неправда. МОжно например вот так

#ifdef A
const bool A = true;
#else
const bool A = false;
#endif

#ifdef B
... 

но это будет много букв.

Дефайны существуют только при препроцессинге

Спасибо кэп!

строку с параметрами компилятора вкомпилить же, ну

О! В смаке это наверное можно сделать, а в питоне распарсить.

Спасибо.

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

Вообще то там дефайны так и работают - есть/нету.

Это неправда. МОжно например вот так

Я бы так и рекомендовал. Уж точно парсить строку с опциями компилятора не стоит, это как раз и будет костылем. Зачем их парсить, если компилятор их уже распарсил и сгенерировал код в соответствии с ними?

Так скорее всего тебе какой-то конкретный флаг и/или значение и нужены. Практика показывает, что лучше и проще вычислить подобное значение на этапе конфигурации(сделать дифайн с нужным значением cmake’ом) или препроцессинга(вычислить с помощью макроса) и оставить в коде константу с нужным значением в нужном целевому приложению формате. Все флаги сборки ведь придётся ещё раз парсить в рантайме, притом API которые про их структуру и назначение ничего не знают, и это речь ещё не зашла о кроссплатформенности (как будешь обрабатывать /D vs -D например).

Ну да, почему-то сначала понял это именно так.

Ну можно еще просто погрепать смаке конфиги на предмет сборки модуля, и на предмет CMAKE_C_FLAGS и CMAKE_CXX_FLAG скорее всего все флаги там, ну если писатели тех конфигов не саботажники.

Так скорее всего тебе какой-то конкретный флаг и/или значение и нужены.

Точнее дцать флагов, которые МОЖЕТ БЫТЬ нужны. А может и нет…

API которые про их структуру и назначение ничего не знают

про назначение не знают (это знает юзер), а про структуру все просто - есть/нет.

и это речь ещё не зашла о кроссплатформенности (как будешь обрабатывать /D vs -D например).

Ну в питоне это совсем просто;-)

С-но я думал что м.б. в питоне уже есть какое то готовое решение по этому поводу…

Ну можно еще просто погрепать смаке конфиги на предмет сборки модуля

Или обсудить с заказчиком какие именно ему флаги в питоне могут понадобится;-)

Ок, спасибо, по крайней мере два варианта есть.

Точнее дцать флагов, которые МОЖЕТ БЫТЬ нужны. А может и нет…

Дык этож и не проблема, тем более если это просто флаги. Можно вообще сделать примерно так:

//temlate.h.in

bool flags[] = {@@CMAKE_VAR_1@@, @@CMAKE_VAR_2@@,....};

# CMakeLists.txt
configure_file(temlate.h.in temlate.h)

//main.c
#include temlate.h

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

О, смакомагия;-)

Спасибо, пошел пробовать.

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

Не, этого у счастью не будет.

Я смаке то невзлюбил, мне гну маке как то понятнее…