shorten logging filenames when built outside of the source tree
conversation from https://gerrit.osmocom.org/5265
Why do we see ../../../ in the file names? We switched logging to __BASE_FILE__ to avoid this on src vs. build dir builds.. I have no idea, maybe __BASE_FILE__ isn't working out as expected? I build in this dir topology and usually see the long ../../ paths: ./src/osmo-foo/configure.ac ./make/osmo-foo/Makefile Can confirm though that LOGP macros use __BASE_FILE__. "__BASE_FILE__ This macro expands to the name of the main input file, in the form of a C string constant. This is the source file that was specified on the command line of the preprocessor or C compiler. " So it's not related to stripping path elements. If we did something like 'cd $(srcdir); gcc -o $(builddir)/thing.o' the paths would go shorter. I'm not so sure on when __BASE_FILE__ != __FILE__, maybe we should go back to __FILE__? stackoverflow has #define __FILENAME__ (strrchr(__FILE__, '/') ? strrchr(__FILE__, '/') + 1 : __FILE__) which would iterate around in file paths for each log statement. compared to terminal output that's probably neglectable.
- % Done changed from 100 to 90
(apologies, somehow this must've slipped by my issue sweeps for a long time.)
We have 'logging print file basename' for a long time now, so the shortened file name feature is pretty much resolved.
But still, we should not use BASE_FILE, which only coincidentally is the same file name that we expect to see. If we had a function that logs and that was defined in an included file, BASE_FILE would indicate the first file where the #include is, and not the file where the function is defined. BASE_FILE works because we don't ever include function definitions that log something, so BASE_FILE always coincides with FILE for our logging; but still BASE_FILE is semantically the wrong constant.