configure scripts need to be runnable with a POSIX-compliant /bin/sh.
On many (but not all!) systems, /bin/sh is provided by Bash, so errors
like this aren't spotted. Notably Debian defaults to /bin/sh provided
by dash which doesn't tolerate such bashisms as '=='.
This retains compatibility with bash.
Fixes configure warnings/errors like:
```
checking whether make supports nested variables... (cached) yes
configure: 3698: CXXFLAGS+= -Ofast: not found
```
Signed-off-by: Sam James <sam@gentoo.org>
Enable `-Wall -Wno-unknown-pragmas` compiler setting to show warnings
during build.
Supress "unknown-pragmas" warning though because it's legitimely used
for openmp support.
Signed-off-by: Olli <oparviai'at'iki.fi>
- Migrate configuration.ac file to new autotools
- add building of also the dynamic-link version within
'source/SoundTouchDLL' directory from the main-level makefile
- add a simple lazarus/pascal example project that uses the dynamic-link
version of the SoundTouch library
Signed-off-by: Olli <oparviai'at'iki.fi>
Add a empty mock "soundtouch_config.h" file and remove "CMAKE" compiler
definition that was used in #ifdef that skipped including
"soundtouch_config.h" in cmake build.
This is to avoid errors about missing include file when not using
autotools build.
Also update version to 2.3.1
Signed-off-by: Olli <oparviai'at'iki.fi>
we need use += and a space CXXFLAGS+=" -O3 -ffast-math" , if not += you override all system settings for CXXFLAGS and none for LDFLAGS, which ends with "/usr/bin/ld: /tmp/ccARck2g.o: relocation R_X86_64_32 against .rodata.str1.1' can not be used when making a PIE object; recompile with -fPIE`"
https://stackoverflow.com/a/38579792/778517
Only gcc in the x86 architectures contain cpuid.h. Therefore this would not
compile in other architectures.
.
To fix this:
1) Pass a warning instead of an error saying that the header file is missing.
2) Disable optimizations if cpuid.h was not found.
.
Behaviour:
1) In non-x86 architectures we have no cpuid.h. We give a warning which I hope
makes sense and is basically saying this is normal in non-x86 architectures and
and we will ALWAYS disable the optimizations.
2) In x86 architectures with cpuid.h we get the desired behaviour and check if
the user request optimizations and if they are supported by the cpu.
3) In x86 architectures w/o cpuid.h we give a warning basically telling the
user to upgrade gcc and we ALWAYS disable optimizations since we can only tell
there is sse/mmx support at build time but not at runtime.
4) In non-x86 architectures with some unexpected cpuid.h the sse/mmx checks
should fail and these optimizations will get disabled.
.
Tested in:
amd64, i386: x86 + cpuid.h
armel, armhf: non-x86 + no cpuid.h
armel, armhf: non-x86 + dummy cpuid.h to pass test
.
The last test should simulate the case of an x86 with no mmx/sse (old i386).
The 2nd test should be equal to x86 + no cpuid.h.
Author: Miguel Colon <debian.micove@gmail.com>
