Am 21.01.2018 um 04:00 schrieb dick balaska:

>> - a build process shouldn't expect any of its build steps to core dump;
>> if a build tool is that unstable, it shouldn't be used at all.
> 
> It's not the build that cores, it's test/debug runs.  Clean also deletes
> *~ and *.bak and other hard coded detritus.

Apparently qmake tries to remove `./source/core`. For that to be a core
dump created during test/debug runs, it would need to run the binary
from `./source/`. That's one of the dumbest ideas I've heard in ages. If
that behaviour is hard-coded at any rate.

My personal guess is that the hard-coded removal of `core` was added
after /some/ user reported an issue where they were left with a core
dump as part of the build process, and instead of investigating the root
cause and solving it cleanly they just patched it up like that without
paying much thought.

Otherwise, if they had done some minimal research, they should at least
have included `core.*` in the list, as Linux systems may be configured
to generate core dumps as `core.PID` - or actually any file name the
administrator chooses. Not that this would solve the problem with the
`core` directory, but I think it is a good indicator of how little
thought went into that hard-coded makefile line.


> Ooh, ooh, I know.  Idiot. What I'll do is create
> ../qt/libpovray/libpovray.pro and build all of ./source from there. (I
> can access ../source).  That'll be messy too, I'll get ../../ blindness
> for sure. But it'll work, and it's better than renaming a primary
> directory.

That sounds neat.

In our Windows project files, we also have an army of `../../` to come
to our aid.

Post a reply to this message