I was always a little sad that povray uses *.ini and *.inc . Something 
with a little more magic would have been nice instead of ubergenerics 
that many compete for. ("Do you want to open MASM?", um no.)

Today I ran into ./source/core .
As in:

rm -f libpovray.a
rm -f *~ core *.core
rm: cannot remove 'core': Is a directory
Makefile:1034: recipe for target 'clean' failed

This is qmake foo.  core is hardcoded into the clean step. :(
google says the only option is to rename this directory. :(
(I fruitlessly tried "QMAKE_CLEAN -= core")

-- 
dik
Rendered 344576 of 345600 pixels (99%)

Post a reply to this message

Am 20.01.2018 um 04:06 schrieb dick balaska:
> I was always a little sad that povray uses *.ini and *.inc . Something
> with a little more magic would have been nice instead of ubergenerics
> that many compete for. ("Do you want to open MASM?", um no.)

Remember that back in the days when POV-Ray was originally created, you
didn't open files from the operating system level; rather, you started
the program that you knew would be able to open the file, and told that
program to open the file.


> Today I ran into ./source/core .
> As in:
> 
> rm -f libpovray.a
> rm -f *~ core *.core
> rm: cannot remove 'core': Is a directory
> Makefile:1034: recipe for target 'clean' failed
> 
> This is qmake foo.  core is hardcoded into the clean step. :(
> google says the only option is to rename this directory. :(
> (I fruitlessly tried "QMAKE_CLEAN -= core")

Hmm... the purpose seems to be to delete any coredump files created
during the build process, which would be named `core` - on /some/
systems at any rate.

I'm hesitant what to make of this. In my opinion, ...

- 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.

- qmake should at least test whether `core` even is a regular file
(which would be the case if it was a coredump) before attempting to
delete it.

Renaming the directory is a step I'd rather avoid; first, because I do
think `core` is a fitting name, and second, because it would create a
"fault line" in the source code version history.

Can you avoid running qmake from the `./source/` directory? That would
be the easiest way out. Remember that you may have two options there:

- Run qmake from the base directory (`./`).
- Run qmake for each sub-directory of `./source/` separately (i.e.
`./source/backend/`, `./source/base/`, `./source/core/`, etc.

I concede that the latter isn't ideal in case more modules are added in
the future, but maybe that's a bullet to bite. As for the only source
file residing in `./source/` itself, `povmain.cpp`, the code in there is
presumably irrelevant for your project.

Post a reply to this message

On 01/20/2018 07:01 AM, clipka wrote:
> Am 20.01.2018 um 04:06 schrieb dick balaska:
>> I was always a little sad that povray uses *.ini and *.inc . Something
>> with a little more magic would have been nice instead of ubergenerics
>> that many compete for. ("Do you want to open MASM?", um no.)
> 
> Remember that back in the days when POV-Ray was originally created, you
> didn't open files from the operating system level; rather, you started
> the program that you knew would be able to open the file, and told that
> program to open the file.

Sure. And on my Amiga, .ini and .inc meant little.

> - 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.


> - qmake should at least test whether `core` even is a regular file
> (which would be the case if it was a coredump) before attempting to
> delete it.

Agreed. "QMAKE_CLEAN -= core" at least should work.

> 
> Renaming the directory is a step I'd rather avoid; first, because I do
> think `core` is a fitting name, and second, because it would create a
> "fault line" in the source code version history.

Yeah, I didn't like it for historical reasons. And because I'm trying to 
be as unobtrusive as possible to the current source.

I renamed source/core to source/povcore just to move on. (Which meant 
editing every single source file that #include "core/blah.h")
I'm not married to the idea, in fact I hate it. But I do have 
libpovray.a and my qtpov built as one executable on Linux. (doesn't do 
shit yet, but it builds)

> 
> Can you avoid running qmake from the `./source/` directory? That would
> be the easiest way out. Remember that you may have two options there:

> 
> - Run qmake from the base directory (`./`).

I already do.  There are currently 4 .pro files.
./povray.pro - point to the other 3 .pro files and build them in this order:
./source/source.pro - build libpovray.a
./vfe/qt/qt.pro - build the vfe interface between libpovray.a and qt gui.
./qt/gui/gui.pro - build the qtpovray gui executable

I broke them up like that because they have different build needs.
Like libpovray is unaware of any Qt gui foo.

> - Run qmake for each sub-directory of `./source/` separately (i.e.
> `./source/backend/`, `./source/base/`, `./source/core/`, etc.

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.

> 
> I concede that the latter isn't ideal in case more modules are added in
> the future, but maybe that's a bullet to bite. As for the only source
> file residing in `./source/` itself, `povmain.cpp`, the code in there is
> presumably irrelevant for your project.
> 


-- 
dik
Rendered 920576 of 921600 pixels (99%)

Post a reply to this message

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