I'm working on a cross-platform project which requires dependencies which are not available on my machine. I basically use a cross-platform tool-chain in docker to build everything. Using buildroot I build a whole Linux system for an ARM platform.
So, I was wondering if there is an option to let Clion know or pick another path for system include header files? Then at least clion can help with code completion etc.
Related
SO!
Let's say I have a number of settings (GCC compiler 9.3.0 built from source, as the distribution I have to use has a very old one, along with environment setup) for a new Kit in QtCreator.
I have managed to setup an environment for compilation and execution of compiled binaries, and made a script to make it work (like qmake -nocache -recursive/make/sudo make install, direct execution of g++, and other stuff).
One thing that script can't do at the moment, is that it cannot create a kit for QtCreator with new compilers and environment being set as required, so after running a script, its user has to go through setting it up himself through GUI, which is bad, because this can cause misconfiguration.
This thing I'm trying to create is going to be used by around ~200 people in my company, so leaving readme.txt with instructions just doesn't go well enough for me - I don't want running around fixing missing "{" and "}" in Environment description in created Kits, and other stuff.
Are there ways to create Kits for QtCreator automatically from command line? Maybe, there's some files to edit?
I've looked into this one a few years back (I wanted to do something similar for registering Buildroot toolchains automatically in QtCreator), and I was unable to find an off the shelf solution. So i think there are 2 ways to implement this:
a) Implementing a command line utility the manipulate the ~/.config/QtProject/qtcreator/{toolchains,profiles}.xml files. Maybe by (re)using the existing C++ implementation within QtCreator, or just re-implement it ie. in Python. Back than I didn't start to work on this as there was no real business need.
b) Switching to qbs, as qbs has support for setting up toolchains from the command line ( see: https://doc.qt.io/qbs/cli-setup-toolchains.html)
If you decide to go with solution a), please let me know and maybe we can partner up to implement it.
Check out the command line sdktool bundled with QtCreator:
The SDK tool can be used to set up Qt versions, tool chains, devices
and kits in Qt Creator.
There still is a lot of knowledge about Qt Creator internals required
to use this tool!
I haven't tried it yet, but I did find the executable under Tools/QtCreator/libexec/qtcreator subdirectory of the Qt Creator installation directory. ./sdktool --help works for me under Linux.
I'd like to use open source library on Windows. (ex:Aquila, following http://aquila-dsp.org/articles/iteration-over-wave-file-data-revisited/) But I can't understand anything about "Build System"... Everyone just say like, "Unzip the tar, do configure, make, make file" at Linux, but I want to use them for Windows. There are some several questions.
i) Why do I have to "Install" for just source code? Why can't I use these header files by copying them to the working directory and throw #include ".\aquila\global.h" ??
ii) What are Configuration and Make/Make Install? I can't understand them. I just know that configuration open source with Windows need "CMake", and it is configuration tool... But what it actually does??
iii) Though I've done : cmake, mingw32-make, mingw32-make install... My compiler said "undefined references to ...". What this means and what should I do with them?
You don't need to install for sources. You do need to install for the libraries that get built from that source code and that your code is going to use.
configure is the standard name for the script that does build configuration for the software about to be built. The usual way it is run (and how you will see it mentioned) is ./configure.
make is a build management tool (as the tag here on SO will tell you). One of the most common mechanisms for building code on linux (etc.) is to use the autotools suite which uses the aforementioned configure script to generate build configuration information for use by generated makefiles which make then uses to build the software. make is also the way to run the default build target defined in a makefile (which is often the all target and which usually builds the appropriate library/binary/etc.).
make install is a specific, secondary, invocation of the make tool on the install target which (generally) installs the (in this case previously) built code into an appropriate location (in the autotools/configure universe the default location is generally under /usr/local).
cmake is, again as the SO tag says, a build system that generates configuration files for other build tools (make, VS, etc.). This allows the developers to create the build configuration once and build on multiple platforms/etc. (at least in theory).
If running cmake worked correctly then it should have generated the correct information for whatever target system you told it to use (make or VS or whatever). Assuming that was make that should have allowed mingw32-make to build the software correctly (assuming additionally that mingw32-make is not a distinct cmake target than make). If that is not working correctly then something is still missing from your system (and cmake probably should have caught that).
But to give any more detail you will need to give more detail about what errors you are actually getting and from what command.
(Oh, and on Windows, and especially if you plan on building your software with VS (or some other non-mingw32-make tool) the chances of you needing to run mingw32-make install are incredibly small).
For Windows use cmake or latest ninja.
The process is not simple or straight, but achievable. You need to write CMake configuration.
Building process is not simple and straight, that's why there exists language like Java(that's another thing though)
Rely on CMake build the library, and you will get the Open-Source library for Windows.
You can distribute this as library for Windows systems, distribute and integrate with your own software, include the Open Source library, in either cases, you would have to build it for Windows.
Writing CMake helps, it would be helpful to build for other platforms as well.
Now Question comes: Is there any other way except CMake for Windows Build
Would you love the flavor of writing directly Assembly?
If obviously answer is no, you would have to write CMake and generate sln for MSVC and other compilers.
Just fix some of the errors comes, read the FAQ, Documentation before building an Open Source library. And fix the errors as they lurk through.
It is like handling burning iron, but it pays if you're working on something meaningful. Most of the server libraries are Open Source(e.g. age old Apache httpd). So, think before what you're doing.
There are also not many useful Open Source libraries which you could use in your project, but it's the way to Use the Open Source libraries.
I am atempting to build a Multiplatform desktop application using WxWidegts. As the IDE I am using Codlite. Version info is
Codlite: Revision 5770
WxWidgets: 2.9.4
OS: Windows 7
Compiler: g++
The problem is, after compiling, trying to start the program will give an error that tells me wxbase294u_gcc_cl.dll is missing. I thought maybe its a debug library thing, so I set the build configs to release but still the same error.
My understanding was that Wxwidgets builds nativly to the OS so it shouldn't be dependant on such a large dll. The dll exists in the libs that was installed by Codlite, but the system does not seem to pick it up.
Am I supposed to build using VC++? not sure how to set that on the build settings.
I've been a WebApp guy for a long time and new to Cross-Platform devlopment, so help me out if I'm going the wrong way.
Thanks in advance.
The wxWidgets library code must be linked to your application code. This can be done in two ways: A) to use static libraries, which are linked to your application executable when it is built, or B) to use DLLs, which are linked to your application when it runs.
From your question, you have built your application to use DLLS.
You have two options to fix this problem. Easiest will be to copy the required DLLs into your application folder.
You can also change the codelite options to use wxWidgets static libraries - you will need a codelite expert to help you to do that.
I took a quick look at the codelite webpage. It does look like codelite uses wxWidgets DLLs by default. To change this, you will need to built wxWidgets the "DIY" way as described here but set the SHARED make option to 0
First, some background: I'm attempting to write drivers and applications for Android on the Beagleboard-xM.
I've downloaded their android development kit, installed it, and can succesfully build everything in it using the directions at http://processors.wiki.ti.com/index.php/TI-Android-ICS-4.0.3-DevKit-3.0.0_DevelopersGuide
I've been able to make my own skeleton kernel module following the steps in http://tldp.org/LDP/lkmpg/2.6/lkmpg.pdf without issues. I can copy the .ko file to the android device, insmod, rmmod, etc.
I got tired of the basic shell given by the default build and thought I'd add busybox. I tried following the directions at http://omappedia.org/wiki/Android_Installing_Busybox_Command_Line_Tools, but I get a compile error on standard libc header files.
After digging around quite a bit, I've determined that the pre-built cross compiler provided in the TI android development kit wasn't searching the right paths.
I confirmed this by creating my own .c file that included and tried to compile it with
arm-eabi-gcc blah.c -o blah
and was met with the same results (unable to find the header file in question)
'arm-eabi-gcc -print-prog-name=cc1' -v gives me this:
ignoring nonexistent directory
"/usr/local/google/home/android/cupcake_rel_root/usr/local/include"
ignoring nonexistent directory "/usr/local/lib/gcc/arm-eabi/4.4.3/include"
ignoring nonexistent directory "/usr/local/lib/gcc/arm-eabi/4.4.3/include-fixed"
ignoring nonexistent directory "/usr/local/lib/../arm-eabi/include"
ignoring nonexistent directory "/usr/local/google/home/android/cupcake_rel_root/usr/include"
None of these paths ever existed on my fresh install of ubuntu 10.04. My cross compiler I used is at /usr/TI-Android/prebuilt/linux-86/toolchain/arm-eabi-4.4.3/. I didn't do anything except run the bit .bin file that was the android development kit (which seemed more like simply extracting itself from the .bin file; I don't remember it doing anything else)
So, a few questions:
how the heck did everything else (i.e. android, x-loader, u-boot, the kernel) build by just putting the bin of the cross compile tool into $PATH (like the how-to documents say). I assume it (make menuconfig?) does some magic in fixing up the include paths based on the location of the executable, but...
Why doesn't busybox work the same way since it seems to be built with a similar looking infrastructure?
How do I make it so I can cross compile my own applications?
I assume I've missed a step and should have done some sort of install/configure on the pre-built cross compiler, but information is horribly scant. I appeal to you, open source gods, to point my way across this dark and stormy sea.
For posterity, it seems that the prebuilt tools included with the android development kit are only enough to build the kernel and don't include libc or other library header files. (The NDK tools are 'different' and the build environment is even more different because it has its own version of libc--bionic. That build environment might have been able to build what I wanted, but I would have had to muck with Androidy makefiles, etc.)
I ended up having to get Code Sourcery arm-none-linux-gnueabi (must get the linux-gnueabi one to have the linux system header files needed), and everything worked reasonably smoothly after that.
I've created, debugged, and revised a project that I've been working on, but now I want to be able to specify what version of the binary I'm on. I'm using Eclispe-CDT with MinGW to make this project on my local system, so there is no versioning software involved. Does anyone know how to specify this for both Windows and Linux platforms?
On Windows, the idea is to produce a COFF file with the relevant information.
That is done by adding a step to the build, using windres (found also here).
See this thread as an example.
you could add windres via the project properties/Builders as an additional builder and add the generated object file in the C/C++ Build/GCC C++ Linker/Miscellaneous/Other Objects.
Then you
- a) could do a clean build if the resource is changed or
- b) could change the build options (if you have patience) to change to do a clean build every time you save the project.
On Unix, this doesn't seem to be supported in a similar fashion.