Всем привет.
есть такой препроцессор m4 можно ли как то прикрутить его так
чтоб первый он обрабатывал исходник .cpp с вызовами m4 макросов
а следом запускался стандартный препроцессор встроенный в cl.exe
скажем для последующей обработки .cpp файла boost::preprocessor'ом
хотелось бы подготавливать данные с помощью m4 макросов используемые
для определения макросов для boost::preprocessor'a но все это должно
происходить прозрачно для файла .cpp исходного кода тоесть после
компиляции в исходнике в месте вызова m4 макроса не должно появлятся
определение нового макроса для boost::preprocessor'а
возможно ли такое ?
например надо такое
в исходнике есть вызов m4 макроса
m4macro(stroka)
он должен раскрыватся в вызов boost::preprocessor макроса
такого вида
boost_macro(s,t,r,o,k,a)
а потом уже boost::preprocessor будет работать с этими данными
или аналогично можно передавать дополнительно их длинну
m4macro(stroka)
раскрывается в вызов
boost_macro(s,t,r,o,k,a,6)
ну и еще всяко можно колдовать с m4 например
вызов
m4macro(stroka)
раскрывается в определение нового макроса и его вызов (рекурсивное определение нужно)
#define new_macro_stroka ...
new_macro_stroka(...)
можно ли как то их вместе связать для совместной обработки
чтобы это было прозрачно для исходника вызов m4 макроса не подменялся на вызов
boost::preprocessor макроса или определение нового макроса и его вызов
а то будет жуткая каша если после компиляции будет менятся исходник
даже если это и будет работать как надо
Здравствуйте, jyuyjiyuijyu, Вы писали:
J>Всем привет. J>есть такой препроцессор m4 можно ли как то прикрутить его так J>чтоб первый он обрабатывал исходник .cpp с вызовами m4 макросов J>а следом запускался стандартный препроцессор встроенный в cl.exe J>скажем для последующей обработки .cpp файла boost::preprocessor'ом J>хотелось бы подготавливать данные с помощью m4 макросов используемые J>для определения макросов для boost::preprocessor'a но все это должно J>происходить прозрачно для файла .cpp исходного кода тоесть после J>компиляции в исходнике в месте вызова m4 макроса не должно появлятся J>определение нового макроса для boost::preprocessor'а J>возможно ли такое ?
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, jyuyjiyuijyu, Вы писали:
J>>Всем привет. J>>есть такой препроцессор m4 можно ли как то прикрутить его так J>>чтоб первый он обрабатывал исходник .cpp с вызовами m4 макросов J>>а следом запускался стандартный препроцессор встроенный в cl.exe J>>скажем для последующей обработки .cpp файла boost::preprocessor'ом J>>хотелось бы подготавливать данные с помощью m4 макросов используемые J>>для определения макросов для boost::preprocessor'a но все это должно J>>происходить прозрачно для файла .cpp исходного кода тоесть после J>>компиляции в исходнике в месте вызова m4 макроса не должно появлятся J>>определение нового макроса для boost::preprocessor'а J>>возможно ли такое ?
PD>VС++ — Project Properties — Configuration Properties — Build — PreBuild Event
в том то и дело что писать каждый раз новую утилиту для
Pre-Build Event не хочется хочется мощный пре препроцессор именно прикрутить
m4 но чтоб работало прозрачно без изменения исходника после компиляции
и философский вопрос зачем было делать такой убогий препроцессор ? почему
было сразу не встроить по мощности сравнимый с m4 чтоб не городить
дополнительные костыли ?
Здравствуйте, jyuyjiyuijyu, Вы писали:
J>в том то и дело что писать каждый раз новую утилиту для J>Pre-Build Event не хочется хочется мощный пре препроцессор именно прикрутить J>m4 но чтоб работало прозрачно без изменения исходника после компиляции
Каккую утилиту и зачем писать ? Там командная строка.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, jyuyjiyuijyu, Вы писали:
J>>в том то и дело что писать каждый раз новую утилиту для J>>Pre-Build Event не хочется хочется мощный пре препроцессор именно прикрутить J>>m4 но чтоб работало прозрачно без изменения исходника после компиляции
PD>Каккую утилиту и зачем писать ? Там командная строка.
я сперва подумал что вы предложили просто свою утилиту в Pre-Build Event использовать
но если вызывать m4 то он будет изменять .cpp файл (я предпологаю еще не проверял)
получится страшное зрелище когда после компиляции все раскроется в вызовы
boost::preprocessor макросов и определения новых как бы так сделать чтобы
.cpp файл не менялся это было бы то что надо (насколько я могу представить)
J>>и философский вопрос зачем было делать такой убогий препроцессор ? почему J>>было сразу не встроить по мощности сравнимый с m4
D>мощный препроцессор означает, что нельзя определить зациклился он или нет, и неизвестно какую вечность будет идти компиляция.
нельзя запрещать то что может навредить при неразумном использовании (я считаю)
а во вторых если бы такой мошный препроцессор был встроен то наверняка
было бы что то типа современного отладчика для неуправляемого кода тоесть
можно было бы если есть подозрения остановить посмотреть стек вызовов диагностика
разная была бы а так мы просто лишили себя удобства и вынуждены приделывать
костыли в Pre-Build Event которые внешне изменяют .cpp файл все равно ведь
прикручиваем костыли но это получается намного хуже если бы это поддерживалось
встроенным препроцессором
Здравствуйте, jyuyjiyuijyu, Вы писали:
J>в том то и дело что писать каждый раз новую утилиту для J>Pre-Build Event не хочется хочется мощный пре препроцессор именно прикрутить J>m4 но чтоб работало прозрачно без изменения исходника после компиляции
Путь 1) (Возможно, самый правильный)
Тебе помогут "Custom Build Rules".
В принципе они предназначены для встраивания сторонних языков программирования, но, IMHO m4+cpp можно считать таковым...
Проблема только в том, чтобы передать настройки (флаги компиляции) компилятора c++ в свою утилиту.
Путь 2)
Когда я вставлял свой велосипедный кодогенератор (это был не m4), то просто вынес все схемы, по которым генерировались cpp файлы в отдельный проект.
Во второй проект включил генерируемые *.cpp, кроме того включил первый проект в "Project Depndencies" второго.
Путь 3)
Выучить синтаксис make файлов. (Там все можно, но придётся вручную прописывать ключики командной строки...)
[offtopic]
По поводу филосовского вороса:
Язык C родился раньше m4.
С++ — наследник С и использование в нем другого препроцессора убило бы совместимость.
При развитии языка пошли не по пути развития препроцессора, а по пути развития шаблонов.
[/offtopic]
Здравствуйте, jyuyjiyuijyu, Вы писали:
J>но если вызывать m4 то он будет изменять .cpp файл (я предпологаю еще не проверял)
исходники можно обозвать например *.cpp4, из них custom build-ом генерить *.cpp, которые впоследствии добавить в проект, и их уже студия будет обрабатывать как всегда, а что компилить раньше, что позже, студия уже сама разберётся.
собственно, таким же образом сделана генерация *_[ip].[ch] из *.idl для COM-интерфейсов.
