CALL_FROM_TEST での分岐で bundle がこわれる

rsk0315 commented 4 years ago

C++ のライブラリ中で

#ifdef CALL_FROM_TEST
#include "path/to/my/library"
#endif

のようにして別のライブラリを #include しようとすると bundle がこわれちゃう。

a.test.cpp 側から

#define CALL_FROM_TEST
#include "path/to/my/library

のようにして #include した場合のみ展開されてほしくて書いていました。

https://github.com/kmyk/online-judge-verify-helper/blob/e0f3c547985e791402a9d951ea56480cc97ea9a2/onlinejudge_verify/languages/cplusplus_bundle.py#L281 つらそう。

rsk0315 commented 4 years ago

oj-bundle でライブラリを運用することを考えると、この種のマクロ自体が不要な気もします。（いま思いつかないだけで、それっぽい理由があるかもしれません？）

kmyk commented 4 years ago

@rsk0315 実際の利用例もほしいです。実用的な範囲内でなら解決できるかもしれないためです。

なお、一般的な解決は明らかに不可能です。実際に提出された後のコンパイル環境のマクロ (標準ライブラリ内で定義されるやつを含む) が不明なためです。展開後のコード量が指数的に増える例とか無限長になる例とかはすぐ作れるはず。

rsk0315 commented 4 years ago

一般的な解決が不可能というのはそうですね。以前使っていた例は、次のような感じでした。

テスト側： https://github.com/rsk0315/library/blob/245b9ba52a0c0a2067cfbec9e007f2ea3e326710/test/aoj_DPL_1_D.test.cpp#L3-L6

ライブラリ側： https://github.com/rsk0315/library/blob/245b9ba52a0c0a2067cfbec9e007f2ea3e326710/DataStructure/wavelet_matrix.cpp#L14-L17

kmyk commented 4 years ago

この例で #ifdef CALL_FROM_TEST と #endif があるのは、ファイルの中身をそのまま連結して (#include の展開はせずに) 提出するためのものということであってますか？

もしそうなら「oj-bundle を使うならこの種のマクロ自体が不要」というコメント https://github.com/kmyk/online-judge-verify-helper/issues/218#issuecomment-609465576 は正しそう。#ifdef CALL_FROM_TEST と #endif を消す方向でお願いします。 (ヒント: awk -i inplace '(/#ifdef CALL_FROM_TEST/ || flag && /#endif/) { flag = !flag ; next } { print }' FILE ... で #ifdef CALL_FROM_TEST と次の #endif を消せる)

beet-aizu commented 4 years ago

https://beet-aizu.github.io/library/verify/test/yosupo/many_aplusb.test.cpp.html https://judge.yosupo.jp/submission/8709 よくわからんが僕のもこわれているぜ！

kmyk commented 4 years ago

https://github.com/beet-aizu/library/blob/240780cad73d47448a50d5e87c4496933093ce67/tools/fastio.cpp

一番上の行に #ifndef call_from_test があって一番下の行に #endif があるので、それらが include guard 扱いされてしまってるぽいですね

online-judge-tools / verification-helper

CALL_FROM_TEST での分岐で bundle がこわれる #218