Ther are many articles about how to install spread library on Linux(1. download source & unzip it 2.run ./config 3. make 4. make install) but seems no article about how to install spread on Windows......
I had downloaded spread-bin-4.4.0-Windows8_x64 from official site(my environemnt is win10), but there is no .bat or .exe file found under the unzipped folder. Does anyone know how to install spread library on Windows?
In linux, there is a standard way of installing libraries that all the software on your machine is supposed to use. In part this works because all that software is chosen in such a way that the same versions of libraries will satisfy everyone, that's what makes up a linux distribution to some extent.
In windows, the model of development is totally different. Any third party software, not from microsoft, is something the customer paid for and microsoft never signs off on it or anything. Third party stuff generally is supposed to provide its own libraries since you have no idea what other third party stuff is present. There's not much point in globally installing things since most programs won't use what you globally install anyways.
So, if you have a library on windows, you should install in whatever way the program that you intend to use it with will find it. If you are intending to install it for use with a project you are developing, that is a different question, and ultimately one about your build system or IDE.
In modern days there are things like NuGet which allow you to do things in a more linuxy way on windows. But that's quite recent and not that much software from typical user's perspective gets its dependencies that way.
After further study, I found a Visual Studio solution file:spread.sln under \win32 folder! So in conclusion, to install Spread libarary on Windows:
1. get source codes from http://www.spread.org/download.html
2. unzip
3. open solution file under \win32 folder with Visual Studio
(Please note that "do not" use relatively new version of VS since this solution is built with older VS(like VS 2010) otherwise unexpected errors occurred)
4. build solution
There you go! You can build your project with Spread library now!
P.S. This spread.sln is a Win32 solution. I'm just wonder is there a Win64 version solution file......
Related
I compiled Qt5 by myself years ago for a Linux project. These days I'm working on Windows and I install Qt5 using the online installer.
Here and there however I face indications that compiling Qt might led to a better debugging experience, last time I notice it was here.
From that days I was using compiled Qt I don't have any memories of better experience than using the online installer.
So I would like to know more about the possible benefits of using a Qt compiled by myself. Is it worth it? Does it give me any extras compared to the online installer?
TLDR: You can use the online installer for initial development and works great with Qt Creator. Maybe later, you might need to build it yourself.
Qt's Windows installer installs most everything you need - including pre-built reference binaries with the most common options available. Perfect for initial development. There's even an option to install the source with the binaries for easy debugging. Download the symbols too if you do this.
You may want to compile the binaries yourself would be for any of the following reasons:
Build with your own custom patches
In case you need to change a build option like the renderer or openssl linkage.
You have a business requirement to build all code you ship.
At least those are the 3 reasons why we build Qt binaries directly ourselves on my team.
I want to use some of the great libraries out there (e.g. cgal), but don't know how (have been exclusively writing my own code so far).
It seems every library requires a different process in order to use it (at least on windows)
I'm currently using Clion as an IDE in Windows 10 with minGW. I've tried using the Conan dependency manager but couldn't get it to work (and the documentation/video tutorials are not done very well).
Is there a recommended simple way to do it?
Is using vcpkg with visual studio a good way to go about it?
edit: for clarification, I am an academic physicist developing scientific simulations mostly to be used by myself, so I don't have to package my code with all the dependencies included.
Thanks.
I am supposed to build existing Windows 32bit project for Windows 64bit. (and probably linux 64bit too).
The project uses log4cplus library. That one only contains 32bit .lib files at the moment and is shining example of why I hate using libraries in C++ - there's just a bunch of source files and linux bash scripts. The INSTALL help file is entirely about the configure bash script which doesn't work on Windows. The configure probably just passes some arguments to GCC, but I don't known which ones.
I downloaded MinGW in hope I'll be able to use mingw32-make on the project and it will work, but no such thing happened.
So does anyone have any experience making those Linux projects on Windows? This is not the first time I tackle this problem - my third most viewed question is about broken Boost build. Judging from the view count, I'm not the only one who has problems building Linux project on widnows.
log4cplus maintainer here.
The master branch of log4cplug GIT repository is C++11 only. Because of this, it requires Visual Studio 2015 and thus the msvc14 directory is there.
Branch 1.2.x and its releases come with Visual Studio project files for version 2010. However, you might be able to build it using CMake for even older Visual Studio.
However, both of them, in any configuration, should have no problem building for AMD64 platform.
I also suggest that you read the README.md file. It documents many things, some of which might be useful to you, too.
My company is thinking of dumping InstallShield and move to something else, mainly because of the poor experience it had with it, mostly on Linux.
Our product is a C++ application (binaries, shared libraries) targeted at Windows and Linux (Red Hat).
The installer itself isn't required to do anything special, just dump some binaries and shared libraries and sometime execute an external process. Things like version upgrading through the installer isn't necessary, this is handled after the installer finishes.
I thought of suggesting using NSIS on Windows and RPM on Linux.
What are the recommended installer systems to use when deploying to Windows/Linux? Something that is cross platform to prevent maintaining two installers is a definite plus.
For Windows I would definitively use NSIS. It's very lightweight, easy to code and very simple to understand. Using msis would just be a killer - it generates guid for every file so you can get upgrades for free and stuff but truth being said, you never end up using any of these.
Regarding Linux I would go for RPM and Deb. They're probably the two biggest packaging system so you'll be targeting most of the Linux users. I've never tried RPM but creating a Deb package is fairly straightforward.
See also:
What to use for creating a quick and light setup file?
Packaging to use to deploy cross-platform?
And even:
Creating installers for complex cross-platform programs
There's a tool called BitRock Installer which can create installers for Windows, Linux and OS X.
However, I think that if you target RedHat it would be better to provide native packages for that platform (that is .rpm).
For C++ projects, I'd go with cmake/cpack, if you are also willing to change your build system. Great support, strongly cross-platform. cpack has various generators, NSIS is one..
Take a look at InstallJammer. It will handle both platforms from the same build project, and you can have the installer register the package with the RPM database as well if that's your requirement.
You may want to consider our tool BitRock InstallBuilder , it can generate installers for Windows and Linux from a single project file and also RPMs. Is your application based on Qt? Our clients include the makers of Qt, Nokia (previously Trolltech) and they use it to package their Qt Creator product. We encourage to give InstallBuilder a try and contact our support with any questions or suggestions you may have.
I'm involved in C++ project targeted for Windows and Linux (RHEL) platforms. Till now the development was purely done on Visual Studio 2008. For Linux compilation we used 3rd party Visual Studio plugin, which read VS solution/perojects files and remotely compiled on Linux machine.
Recently the decision was to abandon the 3rd party plugin.
Now my big concern is a build system. I was looking around for cross platform build tools. This way I don't need to maintain two set of build files (e.g. vcproj/solution for Windows and make files for Linux).
I found the following candidates:
a. Scons
b. cmake
What do you think about the tools for cross-platfrom development?
Yet another point that bothers me is that Visual Studio (+ Visual Assist) will loose a lot functionality without vcproj files - how you handle the issue with the tools?
Thanks
Dima
PS 1: Something that I like about Scons is that it
(a) uses python and hence it's flexible, while cmake uses propriety language (I understand that it's not a winner feature for a build-system) (b) self contained (no need to generate makefiles on Linux as with cmake).
So why not Scons? Why in your projects the decision was to use cmake?
CMake will allow you to still use Visual Studio solutions and project files. Cmake doesn't build the source code itself, rather it generated build-files for you. For Linux this can be Code::Blocks, KDevelop or plain makefiles or still other more esoteric choices . For Windows it can be among others Visual Studio project files and still others for MacOS.
So Visual Studio solutions and projects are created from your CMakeLists.txt. This works for big projects just fine. E.g. current Ogre3d uses CMake for all platforms (Windows, Linux, MacOS and IPhone) and it works really well.
I don't know much about scons in that regard though, I only used to build one library and only in Linux. So I can't compare these two on fair ground. But for our multi-platform projects CMake is strong enough.
I haven't used Scons before, so can't say how that works, but CMake works pretty well.
It works by producing the build files needed for the platform you're targeting.
When used to target VC++, it produces solution and project files so from VS, it appears as if they were native VS projects. The only difference is, of course, that if you edit the project or solution directly through VS, the changes will be erased the next time you run CMake, as it overwrites your project/solution files.
So any changes have to be made to the CMake files instead.
We have a big number of core libraries and applications based on those libraries. We maintain a Makefile based build system on Linux and on Windows using the Visual Studio solution for each project or library.
We find it works well for our needs, each library or app is developed either on linux or windows with cross compilation in mind (e.g. don't use platform specific api's). We use boost for stuff like file paths, threads and so on. In specific cases we use templates/#defines to select platform specific solution (for example events). When is ready we move to the other system (linux or windows), recompile, fix warnings/errors and test.
Instead of spending time figuring out tools that can cross compile on both platforms we use system that is best for each platform and spend time fixing specific issues and making the software better.
We have GUI apps only on Windows atm. so there's no GUI to cross compile. Most of our development that is shared between Windows and Linux is server side networking (sockets, TCP/IP, UDP ...) and then client side tools on Linux and GUI apps on Windows.
Using with perforce for source code version management we find in quite many cases that the Linux Makefile system is much more flexible for what we need then Windows VS. Especially for using multiple workspaces (views of source code versions) where we need to point to common directories and so on. On Linux this can be done automatically running a script to update environment variables, on Visual Studio referencing environment variables is very inflexible because it's hard to update automatically between views/branches.
Re sync question:
I assume you are asking how to make sure that the two build systems get synchronized between linux and windows. We are actually using Hudson on Linux and CruiseControl on Windows (we had windows first with cruise control, when I went to setup linux version I figured Hudson is better so now we have mixed environment). Our systems are running all the time. When something is updated it is tested and released (either windows or linux version) so you would know right away if it does not work. During testing we make sure all the latest features are there and fully functional. I guess that's it, no dark magic involved.
Oh you mean build scripts ... Each application has it's own solution, in solution you setup up dependencies. On Linux side I have a makefile for each project and a build script in project directory that takes care of all dependencies, this mostly means build core libraries and couple of specific frameworks required for given app. As you can see this is different for each platform, it is easy to add line to build script that changes to directory and makes required project.
It helps to have projects setup in consistent way.
On Windows you open project and add dependency project. Again no magic involved. I see this kind of tasks as development related, for example you added new functionality to a project and have to link in the frameworks and headers. So from my point of view there is no reason to automate these - as they are part of what developers do when they implement features.
Another options is premake. It's like cmake in that it generates solutions from definition files. It's open source and the latest version is very highly customizable using Lua scripting. We were able to add custom platform support without too much trouble. For your situation it has support for both Visual Studio and GNU makefiles standard.
See Premake 4.0 Homepage
CruiseControl is a good choice for continuous integration. We have it running on Linux using Mono with success.
Here is an article about the decision made by KDE developers to choose CMake over SCons. However I've to point that this article is almost three years old, so scons should have improved.
Here is comparison of SCons with other building tools.
Had to do this a lot in the past. What we did is use gnu make for virtually everything including windows at times.
You can use the project files under windows if you prefer and use gnu make for Linux.
There isn't really a nice way to write cross platform makefiles because the target file will
be different among other things (and pathname issues, \ vs / etc). In general, you'll probably be tweaking the code across the various platforms to take subtle differences into account, so a tweak to a make file and checking on the other platforms would have to happen
anyway.
Many OS projects maintain Makefiles for different platforms such as zlib where they are named like Makefile.win, Makefile.linux etc. You could follow their lead.