I am trying to make some F# code conditional based on compile-time environment and can't find any OS-specific definitions that F# compiler would recognise. #if MONO doesn't work. Is there any way to detect OS at compile-time for F#?
I don't think there is any out-of-the box way of doing this. You will need to define your own symbol such as MONO and call the compiler with --define:MONO when building the Mono version.
That said, I would be a bit careful about this - there is no clear concept of "compiled for Mono" in F# and .NET. When you compile F# code, you always get a dll or exe that you can run anywhere and nothing prevents you from copying one build output and running it in another environment.
There is a standard way of detecting where the program is running at runtime using:
Type.GetType("Mono.Runtime") != null
You might have good reasons for wanting two separate builds, but it might be worth considering whether you can just make the appropriate choices at runtime (that probably does not work if you rely on some Windows-specific libraries such as WinForms charting).
I'm a windows developer and I need to use Code::Blocks
to develope multiplataform C++ GUI applications.
After installing Code::Blocks and wxWidgets in my first try to do a simple "Hello World" application, the IDE show me a box with $(#wx)
What is the $(#wx) ?
Googling for tutorials I see this
What is the -g ?
Finally the following error message appear:
For 3 days I'm trying over and over again without success !
I even try wxPack. Nothing works !
With VC++, C++Builder and even wxDev-C++ this is straightforward
Only Code::Blocks is so difficult !
Googling, I find many people with the same error, but the advices they get didn't work for me !
Can someone tell me step by step what I must do?
Thank you.
Your frustration comes, as usually does, from your ignorance. If your are required to learn about C::B, well, that's life. Don't waste time on getting so angry, life is short.
CodeBlocks are not tied to a compiler. You can use VC++, MinGW, TDM-GCC, GCC, etc. Thus, you must tell C::B the compiler to use. You may use different compilers for different "targets" (see below).
C::B is not tied to any library either. If you want to use wxWidgets you must tell C::B about the needed files and where to find them.
It's very common that people who use C::B use MinGW as the compiler. That's why when you first install C::B it searches for MinGW and, if found, set it as the default compiler. You can set your own preference in Settings->Compiler. Same goes for the debugger, usually GDB.
As a side note, be aware that MinGW is ONLY 32 bits. There's a different compiler (MinGW 64). TDM-GCC offers both compilers (and their GDB versions) at once, I recommend installing 32/64 versions in different folders and setting them in C::B as different compilers. For Linux, the "mother" GCC is the de-facto standard.
When you build your app you must define a target. This is nothing else but a way of telling things like "I want a 32 bit library" or "I want a 64 executable". In your required project you may set several targets. Select the desired one before compiling (combobox in the main tool bar).
While developing it's very advisable to set a target as a "debug". This means you want to use the debugger. This requires to use "debug symbols". With GCC (or one of its "children", MinGW...) you acomplish it but adding -g as a flag to the compiler.
Now you understand that probably you set not only one, but several targets like "release 64 exe", "debug 32 exe" etc. Right?
wxWidgets joins in scene
Despite C::B is made with wxWidgets, it doesn't ship with it. Download the version you like from wxWidgets site. While some binaries are offered, if you use some other compiler or some other parameters then you need to compile wxWidgets on your own. See the docs/msw/install.txt and learn about the different configurations (release, debug, static/dynamic lib, etc). Your "target" must match the wxWidgets configuration, so better build several versions, same as your targets. And don't forget to use the same parameters for your app target as you used to each wxWidgets target. You can do this at Project->Build options.
As with any compiler you must tell where to find the libraries and the headers. And the libraries you want to use. The Windows libraries (kernel32, user32, etc, they are a lot, ask in another thread) and the wxWidgets libraries.
When you update your app perhaps you use a newer wxWidgets version, but also want to support an older version with other wxWidgets version. You have several folders. For your project you should update all directories. Can this be done shortly? Yes. in C::B you can define variables(e.g. $wx31dir) and use them like $(wx31dir)/include. Redefining the var saves you a lot of typing.
You can use a global var $(#wx31dir) or several, project fitted vars. Your decision.
Finally, C::B offers a project template for a wxWidgets app. It will ask you some locations (wx dirs) and vars. If you don't understand well what it does, better don't use it and set everything on your own. First time is hard, I know. Go ahead and you'll get it if you pay attention to needed steps.
Have you read the CodeBlocks manual?
Since you having hard time using C::B, I suggest you switch to CodeLite which I find simpler to start with than C::B (My experience). Everything you need is documented on CodeLite Wiki. Creating project is well documented with screenshots but before you compile, open environment variables (Settings->Environment Variables) and add line WXWIN=/path/to/your/wxwidgets/installation and compile as it is explained there.
Ouch....
You do not need to interact with code::blocks at all to use wxwidgets.
You can simple download wx header and binary package (depends of your compiler), place it on directory and import (with #include) it in your source code.
I do not see what is relevant to C::B? You can use any library without compiling and setting any variable in your editor (IDE) - but then you lack of lot of feuters.
I hope that
Using wxWidgets Pre Built Binary in CodeBlocks at wxWidgets wiki
and
Using wxWidgets (MSW) 3.0 Binary with Code::Blocks Scripted Wizard
would be best and useful answer for your question.
Even I want to use wheel for my convenience every day, but I don't want to invent the wheel every day again and again.
Even that your question is about wxWidgets and Code::Blocks for MS Windows, and that the answer links are of the wxWidgets and Code::Blocks own,
For recommended stability, I include the full screenshot of this document of wxWidgets own wiki
and
this of Code::Blocks own wiki
I'm using an external preprocessor (pyexpander) for my cross-platform/cross-IDE c++ project*. GCC already works nicely with the -no-integrated-cpp -B${PWD} option. I could manually preprocess each file into a specific temp dir, then compile the processed files. But is there a better way? Specifically, I'd love to hook the native preprocessors so IDE-level code analysis is happy (code completion and error checking). Any hints how I can achieve this would be much appreciated.
*"But why not use c++ macros?" They can't do macro-macros and I need that.
*"But why not use m4?" Because python happens to already be a requirement for this codebase, and m4 seems to not come with MSVS and thus would be yet another requirement/point of failure. I would still have to resolve the original preprocessor problem.
*"But why not use language something_better?" Because I have no choice in the matter. (Though I would love to use nim all the way!!)
I understand it is somehow making a connection so that a compiler when envokes connects a source code to whatever libraries that it needs to.
But what is going on a more technical level, or better put what do I need to know in order to confidentally compile code.
I'm working with C++ and MinGW, and have started to look into build files and stuff for Sublime Text 2 (Have learned mostly under unix, or Java + eclipse so far). But what I don't understand what is adding a compiler to your path do for you?
Do I need to add it for every folder I want to compile from? Or is it system wide? I'm really learning this stuff for the first time, we we're never showed how to set up development environments or even deploy code on other systems.
You probably mean include paths and library paths in the compiler:
include paths: where the compiler will look for headers; and
library paths: where the linker, invoked by the compiler, will look for binary libraries to finish building your project.
If that is the case, look here for a gentle explanation.
Basically, what is happening is that the compiler looks in certain places for symbols defined by the operating system and other libraries installed system-wide.
In addition to those paths, you need to tell the compiler where to find the symbols defined in your own project.
You may also mean something related to installing the compiler itself or configuring the editor to use it.
In that case, what is happening is that you need to tell the build system where to find the executable for the compiler.
Basically, what is probably happening is that your editor wants to know where the compiler is so that it can provide real time feedback on your code. Adding the compiler to the system path will usually, but not always, solve your problem.
In more detail:
A C++ build is a rather complex tool chain, involving determining dependencies, preprocessing, compiling, and linking. There are tools that automate that tool chain, and those tools are in turn wrapped into the functionality of modern IDEs like Eclipse, Visual C++, or Sublime Text 2. You many need to tell your editor where to find the tools it uses to provide you with those services.
I want to write an own c/c++ IDE with syntax-check etc. And of course I need a compiler-functionality. For this I want to use gcc, I think it is a good option, isn't it? The IDE should not call a gcc-binary to compile, it should include the gcc source code, because after compiling the IDE I want a stay alone executable.
So my question: Is there sth like a tutorial or a good hint how to realize this?
btw it's for Mac, I'll write the IDE with XCode
Thank you!
Use LLVM's Clang and its libClang API, it's built for this purpose. GCC is not made to be used as a library.
You might develop a plugin for GCC, or a GCC MELT extension. But it could be that on MacOSX GCC plugins are not supported yet. You might also look into GCCSense which might fill some of your goals (but I never used it).