Buildd-setup faffing around with __FILE__ breaks my unit tests.

[Sune Vuorela]

On Sunday, February 10, 2019 8:17:00 PM CET Ximin Luo wrote:
> Acceptable usecases are those that make fewest assumptions about the
> behaviour of __FILE__, which has never been guaranteed to do what the QT
> test macro assumes it does.

Let's read the docs:
https://gcc.gnu.org/onlinedocs/cpp/Standard-Predefined-Macros.html

| __FILE__
|
|    This macro expands to the name of the current input file, in the form of a 
|C string constant. This is the path by which the preprocessor opened the file, 
|not the short name specified in ‘#include’ or as the input file name argument. 
|For example, "/usr/local/include/myheader.h" is a possible expansion of this 
|macro.

I think it is perfectly acceptable to expect __FILE__ to expand to the full 
path of the file, given 1) the documentation and 2) the behaviour of most major 
compilers over the last decade.

> I think it's extremely short-sighted (and selfish, actually) to feel
> entitled that non-QT projects should patch away their uses of __FILE__
> *that make less assumptions about what __FILE__ does* but QT should not do
> this minimal amount of work to change one test macro.

What would you suggest changing the macro to ?  I can then try push it 
upstream.
 
> Lots of other test runners do perfectly well without __FILE__, QT tests are
> not special.

I haven't yet found a c++ test system that actually has this feature. The 
internet suggests either rolling your own macro around __FILE__ or pass the 
source dir in thru the build system somehow, or as command line arguments 
Pointers are more than welcome.

If you have any good ideas, I'm all ears, but right now, I don't find your 
style of communication in any way constructive.

/Sune
-- 
I didn’t stop pretending when I became an adult, it’s just that when I was a 
kid I was pretending that I fit into the rules and structures of this world. 
And now that I’m an adult, I pretend that those rules and structures exist.
   - zefrank