update CMake build with platform optimization

[lndpj]

Please continue #1 here because of changed/lost account account credentials.

Build system

• Updated CMake with COMPILER_CXX_FRONTEND_VARIANT
• Reindented CMakeLists.txt with sts=2 ts=2 sw=2 expandtab
• update .gitignore with generated in-source tree files
• Support different HOST/TARGET cross compiling
• add ReleaseStrip Mode
• add LTO support check
• allow optional platform independent OpenGL 3D framework examples to be built by using optional subdirs of examples for each framework adding the SMATH_BUILD_GLFW_EXAMPLES/SMATH_BUILD_GLUT_EXAMPLES as two default frameworks supported.

Usage

cmake . --install-prefix=/usr -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_BUILD_TYPE=ReleaseStrip -DSMATH_BUILD_GLFW_EXAMPLES=ON -DSMATH_BUILD_GLUT_EXAMPLES=ON
-- The CXX compiler identification is Clang 22.1.8
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/lib/llvm/22/bin/clang++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found PkgConfig: /usr/bin/pkg-config (found version "2.5.1")
-- OS: Linux-x86_64 => Linux-x86_64
-- CXX: Clang/GNU
-- Build type: ReleaseStrip
ma-- Using IPO/LTO.
-- Found OpenGL: /usr/lib64/libOpenGL.so
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
k-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success
-- Found Threads: TRUE
-- Found GLUT: /usr/lib64/libglut.so
-- Configuring done (0.8s)
-- Generating done (0.0s)
-- Build files have been written to: /usr/src/lndpj/smath

Source Code

• align power of 2 length Vec/Mat type
• add SMATH_INLINE, SMATH_CONST, SMATH_INTRIN_TYPE and SMATH_ALIGN(x)
• add OpenMP to loops and replace constexpr with SMATH_INLINE
• add AVec3 and AVec3d
• add SMATH_INLINE to other operator/functions
• adapt conversion operators and constructors for alignment

[slendidev]

I'm fine with opening a new PR because of lost credentials, but please don't ignore the feedback and questions I raised there. Here's a summary:

• Why SM_INLINE and not SMATH_INLINE to be consistent with the rest?
• Why is an alignment field necessary? And why should it be a template parameter?
• Why have you removed constexpr in a bunch of places?
• I have no examples for GLUT or GLFW, why are they there? Has an AI hallucinated them?

Please answer those questions.

[lndpj]

• SM_INLINE is shorter. If you prefer SMATH I'll change it.
• vector alignment is necessary for the compiler to recognize the storage as aligned SIMD register if vector length is a power of two. Aligned memory/register move is significantly faster than unaligned. To be consistent with vector size one should not align non-power of two vectors to power of two size by default. Use element-size alignment instead. Optionally vector size padded aligned versions are defined with specifying an alignment like Vec<3,float,alignof(Vec<4,float>)>. The most common used alignment static assertions are:
  alignof(Vec<3,float>) != alignof(Vec<3,float,alignof(Vec<4,float>)>
alignof(Vec<4,float>) == alignof(Vec<4,float,4*alignof(float)>
• See: OpenMP directive in constexpr functions combining it with always_inline and flatten is necessary for all functions calling it for optimal performance gain. For __forceinline functions the compilers optimizer should const-evaluates them during compile time. Even wrapping the inline in another constexpr works.
• The framework example build code supports empty example directories. Supporting optional platform independent framework usage is necessary for creating examples with OpenGL 3D acceleration. The most common application of linear algebra is 3D graphics.

[slendidev]

• SM_INLINE is shorter. If you prefer SMATH I'll change it.

Yes, follow the code convention.

* See: [OpenMP directive in constexpr functions](https://stackoverflow.com/questions/79578733/openmp-directive-in-constexpr-functions) combining it with __always_inline_ and _flatten__ is necessary for all functions calling it for optimal performance gain.

The problem is that now the code is no longer constexpr so it cannot be evaluated at compile time. This can actually prevent compiler optimizations, since calls that were previously constant-folded now have to execute at runtime. Better off without OpenMP in most of these cases since the compiler vectorizes loops anyway. Unless you have measured proof that the code is faster with OpenMP, then I cannot consider the addition of OpenMP worthwhile.

* The framework example build code supports empty example directories. Supporting optional platform independent framework usage is necessary for creating examples with OpenGL 3D acceleration. The most common application of linear algebra is 3D graphics.

This does not address my question at all.

You also didn't say anything about alignment.

[illwieckz]

@lndpj has no idea about what he is doing, he is wasting your time, this is randomly generated AI garbage:

• update CMake build DaemonEngine/Daemon#1994 (comment)