On 06/15/2018 08:38 AM, clipka wrote:
> Am 15.06.2018 um 06:18 schrieb dick balaska:
>> Dynamic optimizations:
>>    CPU detected: Intel,SSE2,AVX,AVX2,FMA3
>>    Noise generator: avx2fma3-intel (hand-optimized by Intel)
>>
>> The "Noise generator" was easy, but the "CPU detected" required that I
>> rename platform/x86/cpuid.h to povcpuid.h because it conflicts with
>> /usr/lib/gcc/x86_64-linux-gnu/5/include/cpuid.h
>>
>> I don't get why, and why that wouldn't also be a problem with the
>> autoconf build.
> 
> I'd say that it's not a problem with the autoconf build because it
> shouldn't be a problem ;)
> 
> Which way round is the conflict? Is `platform/x86/cpuid.h` included
> where the other one should have been, or vice cersa? Also, in which
> source file is the offending `#include` located (and if that's not a
> POV-Ray source file, what's the exact `#include` statement)?
> 
> Does your build process invoke the compiler with a command line
> containing `-I-`? Also, what compiler are you using anyway?
> 

Dub baf.

As I was unwinding what I did to answer your questions (I deleted that 
partially composed post), I realized I straightened out the -I list in 
the same pass that I renamed cpuid.h to povcpuid.h.

So, ignore what I said, everything works as expected. :)
I'm happy with the qmake build on Linux.

My next step is to build a debian package (binaries installer)
and then get the qmake edition on Windows to build.

-------
Oh, one thing I don't like, but am leaving alone,
unix/povconfig/syspovconfig.h contains

#define POV_CPUINFO         CPUInfo::GetFeatures()
#define POV_CPUINFO_DETAILS CPUInfo::GetDetails()
#define POV_CPUINFO_H       "cpuid.h"

and then later used as
#ifdef POV_CPUINFO_H
#include POV_CPUINFO_H
#endif

1) The file cpuid.h contains the class CPUInfo. The file should be named 
cpuinfo.h to match the class.

2) POV_CPUINFO_H looks a lot like the header marker
#ifndef POVRAY_CPUID_H
#define POVRAY_CPUID_H
used to read includes once. It works because of the misnaming.
(My personal style has always been
#ifndef _POVRAY_CPUID_H_
#define _POVRAY_CPUID_H_
)

3) The only option for POV_CPUINFO_H is "cpuid.h" ,
why have it at all? It *is* used as a boolean switch, but wouldn't that 
be better served by a boolean?
I guess it was envisioned at conception as having different values for 
different architectures, but on the core editions Windows/Linux/(Mac?) 
it is only ever "cpuid.h"

I would have preferred
#ifdef HAVE_CPUINFO
#include "cpuinfo.h"
#endif

-- 
dik
Rendered 328976 of 330000 (99%)

Post a reply to this message

Am 15.06.2018 um 21:36 schrieb dick balaska:

> Oh, one thing I don't like, but am leaving alone,
> unix/povconfig/syspovconfig.h contains
> 
> #define POV_CPUINFO         CPUInfo::GetFeatures()
> #define POV_CPUINFO_DETAILS CPUInfo::GetDetails()
> #define POV_CPUINFO_H       "cpuid.h"
> 
> and then later used as
> #ifdef POV_CPUINFO_H
> #include POV_CPUINFO_H
> #endif
> 
> 1) The file cpuid.h contains the class CPUInfo. The file should be named
> cpuinfo.h to match the class.

The file `cpuid.h` just /happens/ to define only that one class these
days. The translation unit's main feature is that it provides access to
the CPUID instruction of the x86 architecture, and the name actually
predates the class. It originally started out as a collection of global
functions, which have now been bundled into aforementioned class.

Since it's not a total misnomer, it has never been renamed, in order to
more easily track the file's history.

The moniker CPUInfo, on the other hand, was chosen because other
architectures may provide CPU information in a different manner.

> 2) POV_CPUINFO_H looks a lot like the header marker
> #ifndef POVRAY_CPUID_H
> #define POVRAY_CPUID_H
> used to read includes once. It works because of the misnaming.

No, it would still work without the "misnaming", due to the header
markers having the naming convention `POVRAY_foo_H`, whereas the
compile-time config settings (mostly) have the naming convention
`POV_foo_H`.

I do concede that it does still /look/ a lot like a header marker.

> (My personal style has always been
> #ifndef _POVRAY_CPUID_H_
> #define _POVRAY_CPUID_H_
> )

That's actually very bad practice, as it is technically in violation of
the C++ standard, which reserves to "the implementation" (*) any names
beginning with an underscore followed by an uppercase letter (**).

(* i.e. the compiler and its accompanying standard include files.)

(* Also reserved are any names containing a double underscore, as well
as any names in the global namespace starting with an underscore.)


> 3) The only option for POV_CPUINFO_H is "cpuid.h" ,
> why have it at all? It *is* used as a boolean switch, but wouldn't that
> be better served by a boolean?
> I guess it was envisioned at conception as having different values for
> different architectures, but on the core editions Windows/Linux/(Mac?)
> it is only ever "cpuid.h"

Not only /was/ it envisioned as having different values for different
architectures, it still /is/. We might for instance decide to add
optimized noise implementations for ARM, where `cpuid.h` would indeed be
a misnomer.

Post a reply to this message