Процедурные макросы живут в своих собственных корзинах, которые компилируются для машины разработки (чтобы их можно было выполнять при компиляции корзин, которые их используют). Соответственно, любые директивы условной компиляции в процедурных макротелах будут основаны на их среде компиляции, а не на вызывающей клетке.
Конечно, такие макросы могутразвернуть до токенов, которые включают директивы условной компиляции, которые затем будут оцениваться в контексте компиляции вызывающего ящика - однако это не всегда возможно или желательно.
Где желательно, чтобы сами расширенные токены были некоторой функциейВ среде компиляции вызывающего ящика необходимо, чтобы макрос определял эту среду во время выполнения (что, конечно, является временем компиляции вызывающего ящика). Очевидно, что это идеальный вариант использования для модуля std::env
.
Однако rustc не устанавливает никаких переменных окружения;и Cargo устанавливает только ограниченное число . В частности, некоторая ключевая информация (например, целевая архитектура / операционная система и т. Д.) Вообще отсутствует.
Я ценю, что сценарий сборки в вызывающем ящике может задавать переменные среды для макроса, который затем следует прочитать, но этонакладывает неудовлетворительное бремя на автора вызывающего ящика.
Есть ли способ, которым автор макроса proc может получить runtime информацию о среде компиляции вызывающего ящика (целевая архитектура и операционная система являются большинствоминтерес для меня)?