Question: How do make a single make file to compile several different systems, environments, and sets of libraries at once?
Info:
I'm a student and as such most of my work is done for the sake of learning how these things work. Right now I'm building a game engine from the ground up. I'd like to be able to make it cross platform in terms of OS, but also for different environments. My target environments are both 32 and 64 bit (my desktop as well as my netbook), with a graphics card and with mesa, and linux and windows. so overall it should out put 8 binaries.
I'm still very new to make, as well as the whole concept of cross compiling. I imagine that the process of compiling more than 1 binary isn't hard. but where I'm kind of stuck is how do i get it to attach the right libraries? The Ubuntu Linux vs the WinAPI libraries, 32bit vs 64bit libraries. etc etc. Is it even possible to get libraries in such a manner?
If you need me to clarify further I can. Thanks.
Addendum: Basically I want to know how to compile headers for drivers i may not have. for example. I want to compile all the files on my netbook, including the ones for openCL, I don't want to run them, as my netbook has no GPU, I just want to compile. conversely, I want to use my desktop compile for my netbook which uses ocelot and mesa for its gpu dealings, but my desktop does not have mesa or ocelot on it. that sort of thing. Thanks.
Related
Back in the days of Delphi 7, remote debugging was mostly ok. You set up a TCP/IP connection, tweaked a few things in the linker and you could (just about) step through code running on another PC whilst keeping your Delphi IDE and its libraries on your development PC.
Today, with Delphi XE2,3,4 you have paserver which, at least at the moment can be flaky and slow. It is essential for iOS (cross platform) development, but here at Applied Relay Testing we often have to debug on embedded PC's that run recent Windows. To do this we have employed a number of strategies but the hardest situation of all is to visit a customer site and wish that one could 'drop in' a Delphi IDE + libraries and roll up ones sleeves to step through and set breakpoints in source code.
It is quite likely - hopefully - that the paserver remote debugging workflow and its incarnations will improve over time but for now I got to wondering how it might be possible to install Delphi + libraries + our source code on a USB key so that with only a minimal, perhaps automated setup, one could plug that key into a PC and be compiling, running and debugging fairly quickly.
I can see that the registry is one of the possible issues however I do remember that Embarcadero once talked about being able to run their apps from a USB key. Knowing how much of a pain it is to install my 20-odd libraries into Delphi though, it is not trivial and needs thinking about.
Has anyone done anything like this or have any ideas of how it might be done?
Delphi does not support what you are asking for. But what you could do is create a virtual machine with your OS, IDE, libraries etc installed in it, then copy the VM onto a USB drive, install the VM software on the customer system, and run your VM as-is. There are plenty of VM systems to choose from.
First, I need to get this out of the way: embedded PCs running Windows?? Sob.
Ok, now for a suggestion: if a full virtual machine isn't an option for this task, application-level virtualization may be. This intercepts registry calls and other application-level information and maps them to a local copy, allowing essentially any application to be turned into a portable version. The good news is that there are free versions of several programs that can turn Windows programs into virtualized apps.
The only one I've personally used is MojoPac, and found it delivered as promised although was very slow running off of a (old, very slow) flash drive.
http://lifehacker.com/309233/make-any-application-portable-with-mojopac-freedom
I haven't used this newer "freedom" version though.
Two other programs I've seen that appear to be popular are Cameyo:
http://www.techsupportalert.com/content/create-your-own-portable-virtual-version-any-windows-program.htm
and P-Apps,
http://dottech.org/26404/create-a-portable-version-of-any-software-with-p-apps/
but I can't vouch for the quality of either of these two.
Hope this helps.
I am using OpenCv 2.4.3. I just downloaded it from their site and used the build that they have made. I did not want to take the headache of building it from the source myself. Anyway, in my machine the haar classifier gives very slow performance to detect faces. In another machine my friend runs it fine.( he built from source with TBB and IPP supprt on in cmake).
Though in the release they say that : "You do not need TBB anymore on MacOSX, iOS and Windows. BTW, the binary package for Windows is now built without TBB support. Libraries and DLLs for Visual Studio 2010 use the Concurrency framework."
I do not know much about these TBB and IPP. Only thing that I understand is making these things available will make multi-threading and parallelism possible resulting to speeding up my program.
Do I need to compile the source with cmake, TBB IPP bla bla... or there is something else that I am missing? Any ideas?
What they say, is that they have the pre-built binaries compiled in a way that does not need TBB, because they use another concurrency framework. So if You don't want to meddle in the library's settings You can use the pre-built version without sacrificing performance. But that is on Windows, iOS and MacOS.
The performance might also depend on the machines parameters (You know, cascades are power hungry), so if Your friend has a stronger machine, he will probably get better results, and OS You are operating, but I cannot tell You which is the best, as I didn't try OpenCV on anything besides Linux.
Can someone explain me difference of these? If the program is platform independent doesn't it make it portable too and the opposite?
Platform independent means, these programs can run in "nearly" all operating systems. Doesn't need to be all, but at least MS, Linux and Mac will be fine to use this word.
And, lets dig out the facts behind the word "platform independent".
NOTE: The following sentences are my opinions. If anyone read, couldn't understand the logic behind or doesn't like, just can press on buttons CTRL + W to close. I noted these because Java programmers getting seriously mad when they face this sentences. But it is always open for discussion.
Check please: http://en.wikipedia.org/wiki/Platform-independent_model
Ok don't break the topic and turn back.
Actually and logically, any program needs a platform installer can't be considered as platform independent. For example, if I can't run Java executables without downloading and installing java runtime packages services etc... So how we can say that it is platform independent. If we can say, so nearly 80% of the windows executables are also platform independent since you can run them with virtual machines or WINE on Linux etc. And sure, if Java is platform independent, PHP, ASP, Perl, Python, Ruby etc. all scripting languages are also platform independent!? Aah, sure not...
Hope you got the logic.
But what we can do is, we can compile our (own) softwares for many different OS's. So our software will be "cross platform"
What can be platform independent in real manner is
(as I wrote in top, my opinions)
Uncompiled assembly, C etc codes...
And when it comes to portable, this is something else. For example, the word "portable software" under "windows" operating system means;
Doesn't use registry or Appdata folder for its files or settings.
Works under its own folder, all files needed for it is located under it's own folder.
Also saves it's settings to a file (ini etc) under it's own folder.
And if we go a bit further in meaning, even mustn't rely on specific hardware/software brand, model or unusual mode (like "x" brand screen card, "y" resolution, "z" release of DirectX etc.). But actually you can just ignore the last detail since this criteria is not mature yet to be accepted by all.
I downloaded Lazarus, but have worked with Embarcadero Delphi IDE too. I have a question about building cross-platform Delphi applications.
How can I build them under win32 environment? I read the wiki from Lazarus site, that explains how to do it, but I still do not understand it. Is is possible to build and compile application under win32 environment for Linux and MacOS? If it is possible, can someone explain ste-by-step how to do it exactly.
EDIT:
Now is the time for talking about the new XE2 version of the Delphi IDE I think :)
Thanks
What you're asking for already exists in the lazarus wiki site, you need to read these articles.
Multiplatform Programming Guide
Cross compiling
Cross compiling for Win32 under Linux
How to Write Portable Code (nice doc from Marco van de Voort)
Buildfaq
While crosscompiling to a non windows target is possible (and not that hard), getting used to fpc/lazarus and crosscompiling in one first step is a bridge too far. This because Linux is not a very homogenous target and dealing with this variation requires some understanding how libraries and linking works on Linux. This defeats one-button downloadable cross-compile setups to "general" linux. I know, such one-button thingies that work out of the box for everyone would be great, but it is just not going to happen (or only forvery limited distribution-version combinations)
Crosscompiling with FPC is not extremely difficult or rocket science, but the amount of jargon and details can flabbergast uninitiated people, and without background knowledge it is hard to diagnose problems as a result of minor misconfigurations
I recommend to first familiarize yourself with Lazarus/FPC, and only then make the crosscompilation leap. (and the already mentioned buildfaq names some reasons).
Bottomline: install lazarus on Windows and start porting your app. If that succeeds, start using a linux install (or VM) to familiarize yourself with Linux, and Lazarus under it. You'll need a linux install anyway to test.
Only then start thinking about crosscompiling to speed up the process.
CodeTyphon is a powerful Lazarus/FPC one click easy installation package for cross platform native development. It already supports 4 CPU/OS hosts (Win32, Win64, Linux32, Linux64), and 16 CPU/OS targets (arm-Wince, arm-Linux, arm-Embedded, arm-gba, arm-nds, i386-Win32, i386-Linux, i386-FreeBSD, i386-Haiku, x86_64-Win64, x86_64-Linux, x86_64-FreeBSD, powerpc-Linux, powerpc64-Linux, sparc-Linux, sparc-Solaris). More are supported in Lazarus/FreePascal, but others are not yet integrated in CodeTyphon. Did I mention that it is free? One code to rule them all ;-)
The point is that you don't have to waste days for setting up your cross platform environment, since someone has already done the hard work for you.
As perhaps you know already, most probably the next version of Delphi will be cross-platform. Also, here are some polls on the matter.
While writing a cross-compiler isn't a thing which interests us very much now, porting a library which was/is Windows-tied to multiple platforms, certainly does.
You can think, for example at VCL (Delphi's standard library). While it was designed for Windows only, it has value in it, and, of course, there are huge codebases which depend on it.
The question is:
Which would be the best approach to made an application / library cross-platform aware ensuring a smooth conversion / upgrade path (as much as possible of course)?
I stress it again, we are not interested which is the best way to do cross-platform development only (there were questions on this theme). We are interested also in yet another requirement: The old code base / installations management.
PS: Experiences and/or methodologies from similar situations with other languages (eg. C/C++) which are regarded as standard practices are welcomed.
Thanks in advance.
Visual component developer's perspective:
Add levels of functionality to your code, so as to be able to add another platform without changing the "Core" of the component.
The compiler hopefully will have a platform switch. (Preferable more than one, working in conjunction with each other. ex. Windows/ARM, Windows/386, OSX/Cacao/386, Linux/Gnome/386).
The Layout structure might look something like this.
ComponentJ.pas
Linux\ComponentJ.pas
Linux\Gnome\ComponentJ.pas
Linux\KDE\ComponentJ.pas
OSX\ComponentJ.pas
386\ComponentJ.pas
ARM\ComponentJ.pas
As an Application Developer:
I'll start by moving all WIN API calls in my code into a group of libraries in a Windows directory as to be able to IFDEF it at library level and translate it into another platform I'd like to support as soon as the compiler becomes available, but only as I come across them.)
This will also add the possibility to add adapters easier for the new platforms.
It in any case is good practice to remove possible dependencies into a central place.
IMHO you can't build a xplatform Delphi and ensure a smooth transition for current VCL applications. It won't work. VCL was (luckily, because it allowed for great applications) designed with Windows in mind, and trying to design a compatible library working on a different platform would just mean longer development cycles and lots of compromises. The outcome will be a library noone would wish to use. Look at what happened to VCL.NET: it was the wrong choice. And it was working on the same OS!
We know that targeting non-Windows platform with native applications needs a native GUI library. We don't care about creating a GUI from scratch, for our application it's the way to go, we don't need Windows GUIs with all their standards under a different OS using different standards - we need to be able to code a fully native GUI for the target OS.
Other applications may survive a GUI porting, but in the long run you don't get a real xplatform tool - you get a tool that may compile for other platforms but brings one platform paradigms to others - and it will also be not welcome by "native" developers on other platforms. If you're a Linux or Mac developer, why should you learn how to work with a library that carries its Windows inheritance to your platform? You'd find it a pain in the ass. If Embarcadero wants to sell XDelphi outside actual developers base, it has to offer much more than a new CLX.
I will pull from some ancient experience in making a code base cross compilable between windows and dos (Delphi 1/Turbo Pascal 7). The rule of thumb was to separate code into multiple units. Try to code WITHOUT using windows, messages or any visual components. If you find you need to make a call to one of these, then place that call in another unit and write a proxy (abstract class that you descend from works well) to dispatch the calls through. When a cross compatible version is released, all that you should have to do is code the other side of the proxy for the new target.
If you're designing a form based system, then try to stick with as many of the standard components as possible. NEVER implement any "business" rules directly in an event, instead place them in another unit and call into the other unit to perform the logic.
Now, there will definitely be changes required to get your final project cross compatible, but by following these simple patterns you should be able to greatly reduce the amount of work it will take.
Experience so far has shown that the best way to get a Delphi app compatible with future versions is to stick to pure Delphi components, and use nothing third party. Such an app will probably suck, but that's how it seems to me. I use lots of third party components, and the apps are great and successful. But the chances of them moving to this future too are not certain, and that may cause problems with such changes, but I'd rather have a great app now and have the problem than have a poor app now and not need to worry about it.
Compromises should not be done too much to make VCL compatible with Linux and Mac. Windows is VCL's root. I'll prefer a new and very clean GUI framework, even though without any backward compatibility. Make VCL fatter and fatter isn't a good idea!
make a cross-platform Pascal compiler
make a cross-platform RTL
put the QT on top
Well, look at freepascal and lazarus
I don't get it. All .NET looks the same to me providing we don't use any third party.
Delphi using standard control is already fully functional but your app would look
like thousands of others.
I think Embar should go for PDA, IPhone, Andriod as Windows desktop already eat about
98% of the market.
Mac is expensive and Linux is no cost at all. No use to go for Mac and Linux. Not worth
the investment.
Well, aside the things said - thanks all - I do think that there we need some additional things:
we need tooling to do the necessary conversions
we need tooling to help us in programming against a (some form of) MVC pattern
Simply pick the latest 4.6 QT and add good integration betwen the Pascal and the QT library.
They have done it before (in the Kylix times). The QT is such powerfull these days.
I believe that QT is even better then VCL and at least 10 times more frequently updated and fixed.
So the plan is simple:
make a cross-platform Pascal compiler
make a cross-platform RTL
put the QT on top
and you will have a first-class natively looking applications on all platforms.
My opinion:
Make cross platform compiler (OS x/Linux/ embedded solutions?/ symbian?). Maybe add ability to compile/convert pascal code into portable c/c++ code to build then on embedded platforms.
RTL have to be separated into cross-platform layer and native layer (as for JCL).
Add new core components for cross-platform compatibility and native components for each supported platform (QT for ex)
Add translation utilities to create/convert between platform's components, for ex: to convert pure windows form into mac os x cocoa's form.
All windows hierarchy of components have to be only upgraded to support x64 with maximum backward compatibility. All cross-platform component have to be in parallel hierarchy.
Next version of cross platform solution can be refactored and can include migration/convertion utility. Due to minimum codebase of cross-platform solutions, hierarchy and classes for cross platform can be heavily changed from version to version to achieve best architecture.
sorry for my English - not a native language (Russian is)!
Make C/C++/Delphi compilers that targets OSX/Linux
Make C/C++ compiler that can be Boosted
Write new VCL-Presentation Foundation (VGScene/WPF alike)
it should not be backward compatibile! Delphi IDE should be
written with such VCL-PF
Component Library should stay as it is (but with improved Data-Binding)
Only provide VCL 64-bit for Win64
Is this a problem?