On Tue, 18 Nov 2008, Szak�ts Viktor wrote: Hi Viktor,
> Because in OS X such experience is simply unprecedented > in the user world, and because it gives _no_ advantage > _at all_ on this platform, which is 99.99% aimed for desktop > users. At the same time it makes the binaries simply unusable, > and broken out of the box. So, I'm not exactly sure this is what > users expect on this platform, at least I haven't heard of > any such Mac users in the last 5 years. In fact 99% of them > doesn't want to or have to know that there is such thing > as a .dylib, and I'm pretty sure they won't want to learn just > to run a Harbour based app. I see only one problem. So far no one invest time to create native MacOSX packages which will put Harbour binaries and libraries in the OS friendly directories using OS packaging system. All of the above what you said is only results of such missing functionality which you mixed with your personal preferences from DOS/Windows. > And I believe it's completely wrong to require installation, > sudo/admin rights and all that crap to just make it possible > to _try Harbour_, or run a simple "hello world", or god > forbid have 2 versions installed in parallel (which is not > something exceptional for a developer). Let alone work with > a _portable_ environment. No, we rather save 1.5MB on disk > (or we target server-side users? hard to tell.). I believe that any manual installation which does not use OS support is wrong and farther workarounds only makes it worse. > Pls tell some advantages this gives, so far you seemed > to have just ignored any points raised in this regard. It'd > be really nice to know the reasons why you insist on this > shared/dynamic/dll thing on all platforms. Because shared linking it's a basic requirement in most of open source OS distributions and without it Harbour will never be accepted as default package in them. I do not want to create Harbour binaries to the end of my days and I hope to see in the future Harbour part of all most popular OS *nixes distribution. In current days real static linking stop to be possible in many systems and number of static libraries is systematically reduced. I do not like it sometimes because still there are situations when full static binaries are usable but I understand the reasons. When bug is found in some library then it's enough to upgrade this library instead of all binaries which may use this static library. Shared libraries for Harbour programmers may give yet another feature when it's not possible to create fully static binaries for some libraries, f.e. try to create sth like that for xWindow. When final user application compiled by Harbour is linked with Harbour shared library then it should be possible to install it with any other libraries located with system if only Harbour is recompiled for this OS. I plan to extend it because static linking begins to be real show stopper in software distribution. Without it I will have to recompile my applications for user host. I do not like such improvement ;-) > Also, what if I'd like to just copy my Harbour devl env to > an USB drive and move it around to another machine? This isn't > possible with Linux either, thanks to the shared feature, and > install-time hard wired lib path tricks. It's possible. It's enough to read one man page and resolve it in few possible ways depending on your personal preferences. And if we drop the ideas with making everything static it will be much easier because Harbour may become part of default OS distributions. Now it's not a problem for users who used to install OS friendly packages with Harbour binaries like RPM or DEB. >> If there is sth wrong with default harbour shared library name >> or location in harbour-*.tar.gz then of course it should be fixed. > There is something definitely wrong, since it doesn't work, > and it never did. ??? Viktor if you do not understand sth then its not a reason to remove it from Harbour. Lorenzo can you explain how you are able to use shared libraries in MacOSX. You and Viktor are using MacOSX. Can you try to create native MacOSX Harbour packages which will put all libraries in all expected places? >> Please do not make anything like that. If you want to unify >> the names then I suggest to remove static binaries from Windows >> builds or call them as *-static.exe. > Have you ever seen such thing on Windows? BTW, I haven't > seen too many programs on Windows in the form of *-dll.exe > either. On Windows - nowadays maybe except the Cygwin world > of horror -, apps are expected to just run with as few .dll > dependencies as possible. All of those are just a way to > make programs get screwed on some environments. I hoped that you will find it as heretic idea for windows world. I'm finding your ideas in such way. BTW AFAIR with MSVC is not possible to create static binaries and they always depend on MSVC CRTL DLLs which has to be install in compatible version in Windows or you should distribute them with your programs. Though it's probably problem only for older Windows which does not have other software linked with this library installed. And to clarify. In MS-Windows full static binaries does not exists because MS-Windows API depends on DLLs. > All in all OS X and Windows is not Linux, and there is no > point in forcing Linux standards onto them IMO. It's not a linux standard. I do not know MacOSX desktop and I used this system only remotely but it's BSD based and everything what I said above about dependencies and shared libraries is also true for BSD, OpenSolaris and most of other system which uses OpenSource code. And of course for big machines with closed source *nixes but here usually base recompilation on final machine is a must so it's yet another problem which I will try to resolve extending HRB format. > [ BTW and slightly off, both Linux and Windows could take long > lessons from OS X when it comes to _desktop software_ installation, > those other two simply cannot get it right. I had to fall back > and recommend XP over Linux on Asus EEE PC, because custom software > installation (= Google Earth and say a bittorrent client) is just > way too difficult - if possible - for an average user on Linux. > No wonder it still couldn't catch up. ] Maybe you should look for distribution when such things can be done in few mouse/keyboard clicks. The problem begins when "average user on Linux" tries to build and install sth yourself ignoring ready to use binaries in distribution repositories. BTW I really think that MacOSX users should create native packages. It will be really productive and valuable contribution. best regards, Przemek _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
