Is it possible to determine on which platform (GNU/Linux, Win32, OS X) my Vala app is running?
As Vala is a compiled language (as opposed to intermediate or interpreted) you can determine the platform using your favorite build tool and use conditional compilation.
Something like:
#if WINDOWS
message ("Running on Windows");
#elif OSX
message ("Running on OS X");
#elif LINUX
message ("Running on GNU/Linux");
#elif POSIX
message ("Running on other POSIX system");
#else
message ("Running on unknown OS");
#endif
The build tool would have to pass -D LINUX, etc to the compiler.
I would be careful and only do something like this as a last resort, because it can backfire. Usually it's better to use cross platform libraries that already handle the differences for you.
BTW: See also how this is done in C++.
Related
I am trying to compile OpenCV3 and put it into Qt project because Qt officially provides MinGW Version, so I didn't use MinGW-w64.
I enabled ENABLE_CXX11 and disabled ENABLE_PRECOMPILED_HEADERS in CMake.
Now the problem is MinGW does not contain std::thread.
I know the mingw-std-threads lib can fix it. but I don't want to modify OpenCV source code. Is there any other way to adding c++ thread feature to MinGW? or tell OpenCV using pthread by CMake?
BTW. I don't want use Qt's MinGW because I think using official MinGW to compile the lib shall be used in any version of Qt.
Update:
In OpenCV detection_based_tracker.cpp, there is a CV_CXX11 Marco choice to the using std thread or the pthread. But I didn't see anywhere define CV_CXX11.
Is part of detection_based_tracker.cpp code:
#ifdef CV_CXX11
#define USE_STD_THREADS
#endif
#ifdef USE_STD_THREADS
#include <thread>
#include <mutex>
#include <condition_variable>
#else //USE_STD_THREADS
#include <pthread.h>
#endif //USE_STD_THREADS
My environment:
windows 7 64bit
cmake-3.10.1-win64-x64
opencv-3.4.0
gcc 6.3
What I tried:
install CMake and MinGW
disable ENABLE_PRECOMPILED_HEADERS in CMake-gui
comment #define USE_STD_THREADS in detection_based_tracker.cpp line 48
configure and generate Makefile
Run mingw32-make
it's successfully compiled, but I have to modify OpenCV source code.
If you use the right version of MinGW, namely MinGW-w64, most toolchains builds have the modern threading features available.
You can e.g. use the installer or install it through MSYS2.
I am currently working with Mach-O Executables on my Mac and A question just came across me, Can a single Fat Mach-O Executable file have multiple purposes? Eg.
Could I Have a single Mach-O Executable File with a Fat Header specifying 2 Executables:
Executable 1 : This executable could be a Dynamic Library allowing Its code to be loaded in external applications.
and
Executable 2 : This executable could be an Executable allowing It to be independently launched through Terminal or as an Application.
I just want to know, could this be possible to have 2 Executables with completely different functions inside a single Mach-O Binary File?
Yes it is possible, but hardly useful. Before I get to why, here's how to create one:
Take this C file:
#ifdef __LP64__
int main(void)
#else
int derp(void)
#endif
{
return 123;
}
Compile it as a 64-bit executable and a 32-bit shared library:
gcc -o t t.c -Wall
gcc -m32 -o t.dylib -Wall t.c -shared
And smash them together:
lipo -create -output t.fat t t.dylib
Now, why is that supposed to be not useful?
Because you're limited to one binary per architecture, and you have little to no control over which slice is used.
In theory, you can have slices for all these architectures in the same fat binary:
i386
x86_64
x86_64h
armv6
armv6m
armv7
armv7s
armv7k
armv7m
arm64
So you could smash an executable, a dylib, a linker and a kernel extension into one fat binary, but you'd have a hard time getting anything useful out of it.
The biggest problem is that the OS chooses which slice to load. For executables, that will always be the closest match for the processor you're running on. For dylibs, dylinkers and kexts, it will first be determined whether the process they're gonna be loaded into is 32- or 64-bit, but once that distinction has been made, there too you will get the slice most closely matching your CPU's capabilities.
I imagine back on Mac OS X 10.5 you could've had a 64-bit binary bundled with a 32-bit kext that it could try and load. However, outside of that I cannot think of a use case for this.
I'm writing some library code, which can optionally make use of a certain C++11 feature (thread_local objects). However, I've found a bug that occurs only with the POSIX threading model (the Win32 one works fine) in MinGW-w64's builds of g++.
So, how can I detect, using the preprocessor, whether the current compiler is a g++ with the POSIX threading model?
g++ -v yields ... Thread model: win32 or ... Thread model: posix depending on the difference, but I need a way to conditionally compile code (to work around the bug) that doesn't involve invoking an extra instance of g++.
Check whether the macro __WINPTHREADS_VERSION is defined. If so, you are using posix threads on MinGW.
For example:
#if defined(_WIN32) && !defined(__WINPTHREADS_VERSION)
Logic for MinGW win32 threads;
#else
Logic for MinGW posix threads or Linux/UNIX;
#endif
Examples/References:
http://savannah.gnu.org/support/?108150#comment0
https://projects.kde.org/projects/kdesupport/emerge/repository/revisions/master/entry/portage/win32libs/libssh/0002-add-a-way-to-test-ssh-connections-on-windows.patch#L114
Sorry in advance for a kind-of-dumb question - I'm pretty new to all this.
So I downloaded asio from here, and tried to #include asio.hpp, but got the following error;
fatal error: boost/config.hpp: No such file or directory
I thought this was rather odd, as it was suppose to be independent of Boost. I poked around a bit, and saw that I needed to define ASIO_STANDALONE, which I promptly did, only to be met with more errors where it tried to #include something else from Boost.
Is there just a big list of all the things I have to #define to tell it to be standalone or something? That would be very helpful.
This is an old question, however i had the same problem currenlty with Visual Studio 2013 and Asio 1.10.6. In Visual there is no switch nor compiler flag for c++11 features. Even with #define ASIO_STANDALONEAsio requires Boost.
Solution is to manually specify that our compiler is c++11 compliant. Just add:
#define ASIO_STANDALONE
#define ASIO_HAS_STD_ADDRESSOF
#define ASIO_HAS_STD_ARRAY
#define ASIO_HAS_CSTDINT
#define ASIO_HAS_STD_SHARED_PTR
#define ASIO_HAS_STD_TYPE_TRAITS
#include <path_to_asio/asio.hpp>
As noted on the Asio website:
When using a C++11 compiler, most of Asio may now be used without a dependency on Boost header files or libraries. To use Asio in this way, define ASIO_STANDALONE on your compiler command line or as part of the project options.
Thus even when ASIO_STANDALONE is defined, Asio will use Boost when:
Using a non-C++11 compiler.
When using certain features, such as stackful coroutines that are based on the Boost.Coroutine library.
With asio-1.10.2, the following program:
#include <asio.hpp>
int main()
{
asio::io_service io_service;
}
compiles with gcc 4.8.1, using -DASIO_STANDALONE -std=c++11 compiler flags. Without specifying the compiler to use c++11, compilation fails when attempting to include Boost header files.
I am going to build a Mac application written in Obj-C with Xcode. For argument's sake let's say it will have 10 optional features. I need a way to enable or disable those features to create custom builds of the application. These builds would be automated (most likely through the Mac OS X Terminal) so I would need a way to state which of these features are enabled/disabled at build time (a configuration file or CLI arguments would be ideal.)
So what is the best way to accomplish this? I'm trying to plan this out before I start coding so that there is proper separation in my code base to allow for these features to come and go. Ideally the custom build would only contain compiled code for the features it should have. In other words I don't want to always compile all the features and condition them out at runtime.
You can use Xcode configurations for this purpose; for each configuration you could include a different prefix header, for example. Then you can trigger builds form the command line via xcodebuild.
If you'd prefer the config file approach, you can use a .xcconfig file instead to define any of the Xcode build settings.
The Xcode Build System Guide describes both of these approaches.
use #ifdef and the -D flag under the compiler flags to control whether stuff is compiled in or out. You can set up lots of different configs this way if you want, and just have the xcode build configurations work nicely.
#include <stdio.h>
int
main (void)
{
#ifdef TEST
printf ("Test mode\n");
#endif
printf ("Running...\n");
return 0;
}
output 1:
$ gcc -Wall -DTEST dtest.c
$ ./a.out
Test mode
Running...
output 2:
$ gcc -Wall dtest.c
$ ./a.out
Running...
source: http://www.network-theory.co.uk/docs/gccintro/gccintro_34.html