The mono installation provided at mono-project.com comes packed with several libraries, such as gkt, making the installation quite large (~280MB or so).
Is there any way to provide users with an installation of "just" the mono environment? I am targeting Windows, MacOSX and Linux.
You might be looking for mkbundle which merges your application, the libraries it uses and the Mono runtime into a single executable image. See under "Bundles" in that page.
If you do this though, it may mean that you are distributing LGPL code with all that this implies.
If you are distributing your app for Mac OS X, there is also MonoMacPackager which offers more advanced support for this. I think they have done a bunch of work in the linker to really minimize the amount of Mono that you have to include. It will actually remove unused code from assemblies that you reference.
Related
I really like live smalltalk environment (though I only experimented a bit with Pharo), but there is one thing why I can't really use it for everyday development. It seems that it is not possible to create a native standalone executable from smalltalk system. The native standalone executable means to create a single executable file (PE on windows, ELF on linux, Mach-O on macosx), that a user could run by double clicking it without the need to install any additional execution environments. Am I missing something and it is in fact possible to create native standalone executable with smalltalk?
If we talk about Pharo specifically. I know that Pharo's environment includes efficient just in time compiler (that generates true native code from Pharo's VM bytecode), I know that the VM image can be stripped down by cutting of the code that my application won't ever need. So basically we already have almost everything (except the linker I guess) to be able to create native standalone executables. Cross-compilation shouldn't be a problem too, if we put all code generation stuff (for all target processors) in the image.
I know that in smalltalk world it is considered to be a good thing to deliver the whole VM image separately from the runtime environment, so the user can hack on software he/she is using. However I don't see any good reasons why it shouldn't be possible to deliver your smalltalk software as fully compiled native standalone executable. Could you please explain me why it is not a common thing to do in smalltalk world? Is there any good smalltalk implementation that allow to do it?
To sum all this. I dream of a live smalltalk environment, where I could develop and test my software, but then (when the software is actually ready for delivery) cross-compile it to native executables for windows, linux and macosx from my single development machine. That would be really awesome.
ironically enough there is one thing that an exe needs to be preloaded. Your OS. See the thing is that C/C++ can be so light because already your OS acts pretty much as the image acts with a ton of preloaded libraries. You need to waste several GBs of memory just get a simple calculator starting. Your OS is a collection of C/C++ libraries.
Things are not any prettier with other languages like python, java etc , even if the app is smaller, they still depend on this libs and they come will quite big libraries that would need installation whether your app use them or not.
Pharo and Smalltalk in general is diffirent case because they aspire to be a virtual OS by itself. The diffirence with a real OS , the smalltalk image is made to be hacked the easy way by a user .
Saying that you can rename the pharo executable, change its icon, disable to IDE tools inside Pharo so your user sees only the GUI of your App. Applications like Dr. Geo and Phratch already do this.
Compiling a Pharo project to a native executable will not make much difference, because a) Pharo is already compiled to a native executable b) you dont need to do that since Pharo is already standalone does not need to even be installed.
My advice is stop worrying about things that do not really matter and enjoy learning how powerful and fun Pharo can be.
Not Pharo, but native, compiled (through ANSI C or its own JIT) smalltalk [applications] (with ability to load pre-compiled DLLs or [JIT-]compile code on demand):
Smalltalk/X
http://www.exept.de/en/products/smalltalk-x.html
or (unofficial enhanced development version):
Smalltalk/X JV branch - https://swing.fit.cvut.cz/projects/stx-jv/
Nearly completely open-source. Everything except librun (core runtime - memory management, JIT, etc.) and stc (smalltalk-to-c) compiler is already open-source. Claus Gittinger / Exept also promised/confirmed they would release remaining sources were they to stop further development (AFAIK, those parts are closed only because of concerns of existing clients).
I highly recommend everyone to check it out, it is a wonder such a great implementation is so little known.
You might also check out Dolphin from Object Arts.
It is windows only, but the very best IDE, bar none.
If you do anything in Smalltalk, you should buy a copy.
(They also have a free non-commercial version, but you will
want to support the kind of craftsmanship behind it by buying
the Pro version. An absolutely kick-ass product, IMHO).
It will produce a standalone exe, if that's what you want.
I made an exe of a medium-featured wiki with it - the exe was
less than 1 MB. That is not a typo.
-Jim
The problem is that Pharo, in that case, cannot be compared to any native compiler like C, C++ or others, but more like java, python, ruby and other languages with a Virtual Machine around.
In these languages, you produce jars, eggs or gems to distribute your project.
In Pharo, you produce a "production image" following technics you already mentioned. But nothing prevents you to deliver an artefact including also the PharoVM (it is 2m large, after all), and you can prepare your apps to detect and open your production image (without having to ask for it).
It is about as practical with Smalltalk as with other languages: not very much. As soon as you create a somewhat larger application, you start depending on other libraries/applications being installed. If you compile them statically with the application, you have now created a much larger application that takes longer to download, and needs to be updated at least as soon as a security problem is found in one of the dependencies. If not, your application is no longer double-click startable.
There are two directions for solutions: web applications, and installers and package managers.
Squeak still maintains its one-click installer, allowing the same set of files to work on windows, mac and linux. Pharo used to have that too, but moved to having separate builds. The need hasn't been so large that the one-click build has been reinstated. It is mostly seen as useful to be able to carry around a cross-platform environment on an usb-stick. With the move to the 64-bit spur vm the dependency problems will lessen as more of the needed libraries will come pre-installed on those platforms.
Dolphin Smalltalk can produce a standalone .exe for Windows.
This is a key feature of the Pro version.
Your dream has been around since the mid-80's and it is called Smalltalk/X.
I am a newbie to embedded developement, as figure shown. I have a small ARM board, AT91SAM7-EX256. I have also a JTAG programmer dongle, too. I am using Linux (Ubuntu x86_32) on my notebook and desktop machine. I'm using CodeSourcery Lite for cross-compiling to ARM-Linux.
Am I right that I can't use this Linux-target cross-compiler to make binary or hex files for the small ARM board (it comes without any operating system)? Should I use the version called ARM EABI instead?
As I see, it's a "generic" ARM compiler. I've read some docs, and there're lot of options to specify the processor type and instruction set (thumb, etc.), there will be no problem with it. But how can I tell the compiler, how should the image (bin/hex) looks like for the specific board (startup, code/data blocks etc.)? (In assemblers, there're the org and load directives for it.)
What software do I need to capture some debug messages from the board on my PC? I don't want to on-board debugging, I just need some detailed run-time signal, more than just blinking leds.
I have an option to use MS-Windows, I can get a dedicated machine for it. Do you recommend it, is it much easier?
Can I use inline assembly somehow in my C code? I dunno anything about that. Can I use C++ or just C?
I have also a question, which don't need to answer: are there really 4096 kind of GNU compilers and cross-compilers (from Linux_x86_32 -> Linux_x86_32, Linux_x86_32 -> Linux_ARM, OSX -> Linux_ARM, PPC_Linux -> OSX) and 16 different GNU compiler sources (as many target platforms/processors exists) around? The signs says "yes", but I can't believe it. Correct me, and show me the GNU compiler which can produce object file for any platform/processor, and the universal linker which can produce executable for any platform.
While Windows is not a "better" platform do this kind of embedded development on, it may be easier to start with since you can get a pre-built environment to work with. For example, Yagarto (which I would recommend).
Setting up an embedded development environment on Linux can require a considerable amount of knowledge, but it's not impossible.
To answer your questions:
Your Linux cross-compiler comes with libraries to build executables for a Linux environment. You have hinted that you want to build a bare-metal executable for this board. While you can do this with your compiler, it will just confuse things. I recommend building a baremetal cross-compiler. Since you're building your own baremetal executable (and thus you are the operating system, the ABI doesn't matter since you're generating all of the code and not interoperating with other previously built code.
There are several versions of the ARM instruction set (and Thumb). You need to generate code for your particular processor. If you generate the code for a newer version of the instruction set, you will likely generate code which generates a reserved instruction exception. Most prebuilt gcc cross-compiler toolchains for ARM are "multilib" and will build for a variety of architectures in both ARM and Thumb.
Not sure exactly what you're looking for here. This is a bare metal platform. You can use the debugger channel to send messages if you're debugging on target, or you'll need to build your own communication channel into the firmware you write (i.e. uart support).
See above.
Yes. See here for details on gcc's extended inline assembly syntax. You can do this in C++ and C. You can also simply link pure assembly files.
There is no universal gcc compiler / linker. You need a uniquely built compiler for each host / target combination you use.
Finally, please take a look at Atmel's documentation. They have a wealth of information on developing for this target as well as a board package with the needed linker directives and example programs. Note of course the package is for Atmel's own eval board, but it will get you started.
http://sam7stuff.blogspot.com/
I use either of the codesourcery lite versions. But I have no use for the gcc library nor a C library, I just need a compiler.
In the gcc 3 days newlib was great, modify two files worth of system support (simple open, close, read, putc type stuff) and you could compile just about anything, but with gcc 4.x you cannot even go back and cross compile gcc 3.x, you have to install an old linux distro in a virtual machine.
To get the gcc library yes you probably want to use the eabi version not the version with linux gnueabi in the file names.
You might also consider llvm (if you dont need a C library, and you will still need binutils), hmm, I wonder if newlib compiles with llvm.
I prefer to avoid getting trapped in sandboxes, learn the tools and how to manipulate the linker, etc to build your binaries.
I have a friend who is was a serious Linux developer but now he's working with C# on Windows and is really loving it. I'm attracted to C# because, like Java, I should be able to compile on one system and run anywhere.
If you are developing on Windows with C#, you're using dot-Net. On Linux and MacOS, you're using Mono.
Other people have posted that Mono is pretty good, no longer a science project, and that most of the core Microsoft functionality is present. But that's not really getting at the questions that I have. I'm wondering:
How does performance of Mono on Linux/MacOS rate against Java? If I want to run fast on all three platforms with the same object code, what's my best choice?
Is it easy/possible/reasonable to use Mono with makefiles and do my development with emacs?
Is there support for code factoring in MacOS and Linux, or am I better off just biting the bullet and doing all of my development in Windows?
How well does Mono work with Subversion and the rest of the open source development stack? How about autoconf? Or is this a completely different way of doing things?
Thanks
I have been using Mono on Linux for about three years and lately have been using it on OS X. Some of the Linux stuff was pretty extensive but the OS X stuff has just been some simple ASP.NET MVC2 apps so far.
1) Performance of Mono has never been an issue for me. That is not to say that performance has not been important, it is just that the performance of Mono itself has never been an issue. A lot of what I have done is web based so I/O and database memory use have hit me before Mono has.
Historically, the biggest deficiency with Mono has been the Garbage Collector (GC). I would say that Java is better tuned in this regard. The most recent versions of Mono have made huge strides in this area but I do not have any hard numbers for you in terms of comparisons.
I am sure Mono is faster sometimes and Java sometimes but I would say that Java is faster overall.
2) You can certainly do Mono development with makefiles. Certainly the Mono team itself does. Also you can certainly use Emacs and there is a C# mode for it.
I tend to use MonoDevelop and xbuild (Mono version of msbuild) myself and do not have any experience doing C# work in Emacs. MonoDevelop is great because it is exactly the same on all platforms. Also, although I rarely use it anymore, it is nice that the project format is the same as Visual Studio and SharpDevelop.
3) MonoDevelop has pretty decent code factoring support. It is the same on Windows, Linux, and Mac. You do not need to use Windows for development (though you certainly can) but I believe you will be happier using an IDE like MonoDevelop. Even things like Intellisense become hard to live without once you are used to them. But integrated debugging, being able to drill-down into the framework, database integration, unit testing, SCM integration, and other nice tooling support all in one place is just the way to go (for me at least).
4) Mono itself does not care about version control of course. Your source files are just text and you could use anything to manage them.
That said, MonoDevelop has fantastic Subversion support built right into the IDE. I have used it extensively and it is one of the reasons I have trouble moving off MonoDevelop even on Windows. The latest version of MonoDevelop (2.6 beta) includes Git support as well.
You did not mention unit testing but MonoDevelop also has NUnit support built into the IDE. I use that on every project as well and it works excellently. The version in MonoDevelop is 2.4.8 (if memory serves) so it is not quite current but it works great.
In a nutshell, Mono works really well with Open Source tooling in general. It has always played really well for me.
Autoconf is of course used by the Mono project itself but, as a Mono developer, I have never seen a need for it. I strive to only use managed code in my projects. As such, all I need on the target platform is Mono (or .NET). Not having to worry about all that stuff is one of the primary benefits of a managed environment like Mono or Java. The runtime itself (the CLR) ensures that my app has everything it needs to function properly.
I know that MonoDevelop will build autoconf/autorun files for C/C++ projects (non-Mono) but I have not done much with it myself.
As to a previous comment, the Mono JIT is obviously tuned to the target platform. That is where platform specific performance tuning happens.
Just as a comment, I find that Mono is best viewed as a development environment in it's own right rather than a compatibility layer for Microsoft stuff. The Mono team has extended .NET in many interesting ways. Anything you develop for Mono will run on .NET but there are some .NET features not available for Mono. For example, Mono does not support Windows Presentation Foundation (WPF). You have to use Windows Forms or GTK# for cross-platform GUI work. You can also use something like Cocoa# or MonoMac on the Mac, MonoTouch on iPhone, or MonoDroid for Android. You can use Moonlight instead of Silverlight as well although I have not played with it much.
One more thing since you asked about Java. I have found a few times that the Java world had libraries that I could not find equivalents for in the .NET world. In these cases, I have had amazing luck using IKVM.NET to integrate this into my Mono apps. IKVM.NET also works on .NET but Mono and IKVM.NET are very cozy and even share some code.
So there you go, one real answer for you at least.
Our C++/QT desktop application for Mac, Windows and Linux needs an installer. I'd rather we have a single installer for all three platforms. I do know it's a bit tricky, I guess what I wanted ask is if a framework already exists for that (Java maybe?).
I'd really like to avoid having to write three different installers.
The link that Kyle mentions is pretty comprehensive, but I wanted to provide a bit more of information about InstallBuilder for Qt (Disclaimer, I am one of the developers) since most of the cross platform installation programs referenced there are Java-based. This requires bundling a JRE, etc. and adds a significant overhead that is not required with a Qt-based installer, like ours. It is able to generate wizard-like executable installers for all platforms from a single project file as well as native packages such as DEB and RPM. If you ship your software in DVDs, you can create a single multi-platform DVD that shares data across platforms but still have native launchers.
Having said this, since your application is Desktop-oriented, for the particular case of OS X if it does not require complex installation you may be better off creating a .app file and package it inside a DMG. Users can then drag the file directly to the Applications folder.
Finally, I wanted to mention that InstallBuilder is commercial, but we offer free licenses for open source projects and discounts for small development firms.
IzPack rocks: http://izpack.org. It is truly crossplatform, very lightweight, easy to master, and produces excellent results.
After fully integrating both Izpack and InstallBuilder into our builds (using Windows, OSX, and Ubuntu 14 build servers for testing purposes), I will say I believe InstallBuilder is well worth the money (and free for open source projects according to wojciechka).
Izpack is a bit slow, a bit large if you need to package a JVM, and has an amateurish user interface. Version 5 (release candidate 3) was also not generating uninstallers properly. That said, as long as you use a 4.x version and require a JVM anyway, it may be enough for your needs. The extension interface is not terribly easy to deal with, but is almost infinitely flexible. The Windows installers do not register with the Control Panel uninstaller list.
InstallBuilder has a great, fast UI in the produced installers and has a serviceable UI for creating installers. The XML is pretty easy to deal with, too. Downloads are about as small as possible. It also includes nice hooks for doing all sorts of custom stuff easily. The only slightly annoying thing I ran into was that the Windows server required that I manually add some configuration to set executable bits on the other systems' packages (other systems didn't require this configuration).
Note: I was using the three-platform version of standard InstallBuilder (not InstallBuilder for QT).
I have a plan to build a web-site which running CGI made with Cocoa.
My final goal is develop on Mac OS X, and run on FreeBSD.
Is this possible?
As I know, there is a free implementation of some NextStep classes, the GNUStep.
The web-site is almost built with only strings. I read GNUStep documents, classes are enough. DB connection will be made with C interfaces.
Most biggest problem which I'm concerning is linking and binary compatibility. I'm currently configuring FreeBSD on VirtualBox, but I wanna know any possibility informations about this from experts.
This is not a production server. Just a trial. Please feel free to saying anything.
--edit--
I confused Foundation and Cocoa frameworks. What I said was Foundation. Basic classes which just enough to manipulating strings.
It’s entirely possible to cross-develop using Xcode. The Cocotron does this – and provides an implementation of Foundation – but doesn’t currently target FreeBSD. You could probably use it as a template to set up cross-development for BSD targets using GNUstep, but it won’t be easy.
You should be OK with the GNUstep Foundation on FreeBSD 9.0 with Objective-C 2 (clang). See these instructions.
Note: Do not installing under '/' with a FreeBSD default install, because it has little space on the '/' partition. I've used /usr/local/gnustep instead, and made some links as the instructions suggest.
Note II: GNUstep sources from subversion repository didn't compile for me, so I used the latest stable GNUstep sources.
Yes, you can do this, and I am doing it right now successfully using FreeBSD 8.2 and Xcode 4.0, running the Foundation class from The Cocotron. Here is a link: describing exactly what I did to build the cross compiler and set everything up. I also detail in that post, how I attempted to get AppKit (GUI) to work. I failed, it may work in the future, it doesn't fully work yet.
So far it's great. I use a common codebase to write iPhone App (game client) and FreeBSD Game Server; after my server compiles I even have a target rsync the files to my dev box.
One more note, you mention DB, I'm successfully using mysqlclient libraries within my App and my post details how to do that. Since you're building a cross-compiler with The Cocotron you can use any library. Just install the library on FreeBSD first, then create the platform as described.
Sounds like your trying to shoehorn tools onto OS and hardware they were not designed for. There are hacks to get almost anything running on top of anything else but why ask for all the grief?
The entire point of the entire Apple API is that you have integration from hardware to OS to development tools. You supposed to pay more up front in return for greater robustness and lower over all lifecycle cost. (It doesn't always work just like Linux doesn't always save money and Windows doesn't always provide the software choices you need but that is the design goal.) When you break Apple's hardware-OS-Dev trinity you have to start fighting the API and the hardware instead of letting it work for you.
I don't think what you're doing will work and even if it does it will cost a lot of time and in the end time is money. Unless your being forced by external circumstances beyond your control to use this configuration, I would strongly suggest you do whatever it takes to find another way to accomplish what you want.
You won't get binary compatibility. Mac OS X uses the Mach-O object format and FreeBSD uses ELF, like linux. Cocoa won't work on platforms other than Mac OS, but if you stick to POSIX and open-source libraries though, you shouldn't have too much trouble building your CGI (and any dependencies) on your FreeBSD machine.
Also, Cocoa for a website? It's the Mac OS standard library for GUIs, associated datastructures, and various helpers. Apple used to promote something called WebObjects which was similar to Cocoa for the web, but I haven't heard anything about it in ages. I don't think Cocoa will work for a website, unless you just mean write a custom web server that has a graphical front-end in Cocoa.