I want to build a program ("exe" or "static lib") using ECL, but under windows. My application must depend on "ecl.dll".
How to modify the MSVC makefile to build ECL statically?
As I explained in the mailing list, ECL's Makefile for Microsoft's compilers currently does not have this option. It simply hasn't been ported from their siblings that run on Unix-type environments. But that does not mean it cannot be done.
Related
Background: I work in a company with many preferences. We currently use makefiles for our complex build with the developer's choice of IDE (or even VIM) for editing source files.
I'm looking at CMake to clean up our un-tame-able gnu make build system. I like the integration with VS Code, but I couldn't possibly manage to dictate the IDE to many of our more prickly DSP engineers and their preferred editing environment (which I totally understand; I'm a bit of Visual Studio guy, myself).
Anyways, is the cmake-kits.json method of specifying kits or toolchains/targets/etc. the "right" way to do it? Or is that just for VS Code.
If it's just for VS Code, what's the proper CMake-y way to put in new toolchains (we do cross compiling using non-gnu tools for 3 different processors) that would work in VSCode, or eclipse, or from the command line.
Kits are part of the CMake extension for VS Code. You want to read cmake-toolchains(7). A kit is something like setting CC and CXX in the environment so CMake knows which compiler to use for Makefile and Ninja generators. It is different for the other generators as the IDE can control which exact compiler is used and you tell CMake which toolset to use and it generates the project accordingly. FYI, kits don't handle having to write your own toolchain file for cross compilers.
You can use a toolchain file for cross compiling. This can be simple to hard depending on the compiler and how well it acts like a gcc cross compiler. If it's really different a toolchain file isn't quite enough as you then need to update the platform items to get it all working. Since this gets into the area of being CMake implementation dependent it's not that well documented. But there is help at https://discourse.cmake.org/.
You could just use Ninja as the build tool. Then you setup your toolchain file. After your original run on CMake to create the Ninja project files, you can just run Ninja to build the software.
Then it's easy to set your IDE to just call Ninja to build the software.
Personally, I don't like the CMake integration in VS Code (it's just an add-on). It's always been too buggy for me to want to use it. But it was good for pulling the information out of the build to get the cpp-tools setup correctly. As for project files for Eclipse CDT4 - Ninja I've never personally used them.
I have begun to use GTK(2), and I find that the workings of the library to be very good, but the documentation sucks.
I want to upgrade to GTK3, but it seems I need to install something called packman. That is a difficult philosophical step for me. Why can't I simply download a zip file(s) somewhere?
The documentation uses a lot of words without saying much, and the downloads want you to download stuff OTHER then gtk in order to get gtk. Why don't they simply have a GTK package and let me decide if I need all the other stuff.
Also, I have been reading on forums, even if I do the packman stuff, it still isn't enough for C::B.
Anyway, that is mostly a rant, what I'd really like is a suggestion to an alternative to GTK+.
Here are some of my requirements...
#1, It must NOT be an interpreter. Using Code::Blocks and C, I get an exe file and I'd like to continue that way.
#2 It must be programmable using C. I'd really like to stick wiith C::B, but I guess in a pinch I can use Eclipse (although that is another nightmare I won't get into here.)
#3 GTK requires a bunch of DLL's to be shipped along with the exe file. It would be ideal if the entire target could be included in the single exe without having to rely on external dll's or .net framework or other external stuff.
Any suggestions woule be apreaciated.
Thanks, Mark.
You best bet is to give a look at https://en.wikipedia.org/wiki/List_of_widget_toolkits#High-level_widget_toolkits
If you wan to stick to C and not C++, then Qt is out.
The other that stands out is EFL. I've never used it myself, but it has good reputation and probably your best bet if you want to quit GTK+ and stick to C. However I don't know how easy it is to use it on Windows.
Now about GTK+:
Also, I have been reading on forums, even if I do the packman stuff, it still isn't enough for C::B.
There are people here that use GTK+ with Code::Blocks, so I don't get what kind of problem you're referring to.
Then your other problems:
The documentation uses a lot of words without saying much
Examples?
the downloads want you to download stuff OTHER then gtk in order to get gtk
What you don't get is that GTK+ is more that just the libgtk library. It has dependencies on a lot of other libraries, like glib, cairo, pango, etc. In the past there used to be a bundle or installer to have that installed on Windows, but people would mess up on setting the environment up based on their needs and give up. As the GTK+ manpower for the Windows platform is limited, the GTK+ team delegated the distribution of the GTK+ binaries to the MSYS2 project.
MSYS2 is a popular project that provides a lot of open source software already built for Windows, and solves the problem of building and installing dependencies by hand for the user. This step is made to make installation simpler, not harder. In a handful of commands you have GTK+ and all its dependencies installed for your platform, and can start coding your app. Another command and you have python and the python GTK+ bindings installed and can get started. Want to depend on another popular library? Chances are MSYS already provides it.
Windows has been known for decades to be bad on dependency management. If package management wasn't a a pain point on Windows, then stuff like chocolatey or conan wouldn't exist.
Your philosophical reluctance is merely that: philosophical. Sure GTK+ on Windows isn't perfect. With MSYS2 you will get packages built with gcc so the debug symbols are not compatible with the Visual Studio debugger and you will need to use gdb instead. But on your other question you say you use gcc and loathe Visual Studio, so this should not be a blocker to you.
GTK requires a bunch of DLL's to be shipped along with the exe file. It would be ideal if the entire target could be included in the single exe without having to rely on external dll's or .net framework or other external stuff.
This is not possible for the moment as static compilation of GTK+ isn't supported. The redistribution of an app, however, isn't as easy as I'd like it to be. The best way on Windows to redistribute your app while using MSYS2 is to create a pacman package for your app, listing its dependencies, then call pacman to install your app on an empty directory and tell it to install all your dependencies there too. The result will be a directory that you can redistribute, with a self-contained installation of your app and all its dependencies, GTK+ included.
biicode is a dependency management system for C++. I use the Intel C++ compiler (ICC), rather than gcc. Is it possible to use biicode, but continue to use ICC for building my project and dependencies?
As biicode uses the CMake build system, it should be possible just indicating CMake that you want to use that compiler. Depending on the platform it can be done differently. You can find info about setting different compilers here
E.g. in Linux, it could be enough to define environment variables:
CC=icc
CXX=icc
bii build
You can pass variables and options to cmake project configuration with the command bii configure, exactly as they would be passed to cmake, e.g. the generator:
bii configure -G "Visual Studio 12" -DMY_OPTION="myvalue"
So you could try something like:
bii configure -D CMAKE_CXX_COMPILER=icc
In win with VS, you might need to set the toolset, this can be done with something like this in your CMakeLists.txt:
set(CMAKE_GENERATOR_TOOLSET "Intel C++ Compiler XE 14.0" CACHE STRING "Platform Toolset" FORCE)
Though in general, specific configuration of compilers in the CMakeLists should be avoided and setting the environment via env or variables is preferred.
I am a very new to porting.
I was trying to port perl to a netbsd system. Since its a custom made build, we wont be able to run configure or make on the target netbsd system. So we are trying to cross-compile it in a host pc and copy the binary over target machine. And in order to do so, we have to make a makefile from scratch, since the format for the makefile in our build is different.
I have some basic doubts regarding this,
Firstly, In order to create a perl makefile for my custom build, what are the basic things will come. Such as ccflags, library paths etc.,?
There are some files like DynaLoader, uudmap.h, myConfig, Config.pm which gets generated while "make". How can i generate them using custum makefile.
How to set various library paths and what are they ?
The #INC, shows the perl search paths, how can i create it ?
Where exactly Perl modules get installed and when it happens?
A perl build normally involves building a stripped down version of perl named miniperl, which is then used extensively in the remainder of the process of building perl and the bundled modules.
There are two basic approaches to cross-compiling: to build miniperl for the target machine and build the modules, etc., there, or to build miniperl for the host and use it to build perl and modules for the target.
The WinCE port uses the latter approach; the rudimentary (last I knew, anyway) support for a -Dusecrosscompile switch to Configure uses the former.
I recommend you ask for advice and help on the perl5-porters mailing list: http://lists.perl.org/list/perl5-porters.html
And be prepared for hard work.
NetBSD's pkgsrc system has perl in it already and has the ability to generate binary packages that you can then install on a target machine.
I had developed a small program in netbeans using c++. I need to know how can i deploy/run the package on another linux system
Abdul Khaliq
I have seen your code, you probably missing XML files in the current folder... where the executable is located... paste then and then run as ./your-executable
I recommend that you use a makefile to recompile on your target machine which will ensure that your program is deployed properly.
You should use a makefile as suggested. I know that NetBeans can generate one, but it's been a while since I last did so. Maybe this can help: http://forums.netbeans.org/topic3071.html
Typically, once compiled, your executable will need several libraries. Chance is that those libraries will also be available on the target linux system.
Thus, you can simply copy your executable over to the other system. If you run ldd on your executable, you should see the list of libraries your executable is dynamically loading. Those libraries should be available on the target system as well.
In case your executable makes use of resources such as images and other binary files, you can use a resource system (e.g. Qt Resource System) and compile those binary files into your executable.
The easiest way to test is to do the copy, run
ldd yourExecutable
on the target system. It will tell you if you are missing any library. Install those libraries using the system package manager.
Of course, you also have the option to statically build all libraries into your executable. However, this is not recommended since it makes the executable too large and complicates matters.
What type of package is your netbeans compiler creating? deb,rpm? If you are moving the package to a different linux install you will need to use that distributions package type. Ubuntu - deb
Fedora/Redhat - rpm
etc...
I'm not sure how you change this in netbeans but I'm pretty sure it has the ability to. A google search could help you more.