Hi Przemek,
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.
Hm? In OSX the preferred distribution is .dmg for desktop
apps and there is really no standard for command line ones.
Any solution with an installer would just ruin the experience
and limit usage, so please don't try to make it any worse
by pushing such a solution.
Harbour on OS X is broken because you seem to have a personal
preference to force dynamic libs.
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.
I believe that any "installation" procedure is fundamentally
wrong and highly limits usage. See my concerns, which you've
just ignored.
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.
Now the situation you say is very very remote for a default
hbrun/hbtest installation. It's also very very remote for
those small apps one would create using hbmk script.
I've nowhere said Harbour shouldn't support dynamic linking
per se (in fact I've spent quite some time making them build
in Windows, even if I don't use them), all I'm saying is this
shouldn't be the default for hbrun/hbtest (on OS X), and
for hbmk (on OS X).
For larger projects everyone is free to decide to use a
dynamic lib or static, or to package final executable in an
.app (with or without dynamic libs), ship it using whatever
method. Harbour should ship the .dylibs, but it shouldn't
be needed to run supplied executables, simple because it's
broken, limits usage and completely unnecessary.
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 ;-)
You're talking about something different. See above.
Supplying dynamic version of hbrun doesn't really have
anything to do with the above.
BTW, in OSX there is _no_ desktop app (except some ill-
behaving ones), which would need a classic installer, and
which would require to copy some libs to system dirs or
whatnot. These apps may use dynamic linking inside, but
from a users POV it's one entity and all what you say
above is moot, because there's hardly any situation where
you'd just replace the ".exe" while leaving a 3rd party
".dll" around. Any programs requiring an installer on
OSX are largely considered as more dangerous and
ill-behaving. Only those apps use it which need to
install .kext files or some other frameworks (for no
good reason usually), some do it to copy the .app "file"
on behalf of the user (quite useless) and these app
are rare. Microsoft is one such vendor in the OS X scene.
[They probably also badly miss a registry in OS X.]
About static/dynamic you didn't convince me at all.
All I see is that you seem to prefer it and everything
else is just ignored.
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.
There is no such thing in OSX.
.rpm and .deb will makes it impossible to have two versions
of the same package in parallel. This pretty much makes them
useless for some, so please don't try to force it, especially
for other OS X.
So, how do you address that? How to move around a Harbour
in non-standard places? How to place it on a USB stick? (on
Linux, OS X you name it)
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.
Did I miss a proper reason for them?
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?
There is _no_ installer in OSX! No one would put anything
to specific places. I expect to unzip it and use it, period.
I know how to make .dylib work for default Harbour, you have
to copy it to bin dir and use -static. Beautiful solution.
And now you propose to make it even uglier with an installer.
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.
Please let's not move this talk to some academic level
plus some nonsense (of course the OS is separate!). The
point is around "harbour.dll" not system .dlls.
You're also wrong, because with MSVC you can create .exes
which don't need CTRL .dlls, so what you say can be
avoided (which I _had_ to do to make my app run on any Windowses).
MinGW is the one which is unable to create self-contained
(disclaimer: except the OS itself naturally) executables.
And this is perceived as a limitation. Not to mention
Cygwin, with its cygwin1.dll (and others). This is the reason
I avoid them like fire, maybe I'm not the only one. It
really starts to get funny when you have multiple incompatible
versions of cygwin1.dll. Some installers event went as far
as to try to detect it and make attempts to "correct" it.
It's a bad joke.
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.
It's not Linux standard, it's something fundamentally wrong
from an end user perspective. All the systems above won't be
used by "normal" ppl, OS X is the only one which is. Probably
that's the reason, not that wanted to speculate on that.
I believe in clear separation of components, the OS, the apps
from the OS, the apps from themselves.
If your aim is to make Harbour as part of open source OSes
it's fine, but chances are low you'll make it part of OS X.
Of course we should allow it, but for god's sake lets not
optimize for such a remote possibility by default.
[ 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.
<OFF>
It's a Debian based distribution, but anyhow please don't advise
to start with reinstalling the OS, because this would also
ruin the experience plus I'd expect it to not work anyway.
Which normal computer user has or wants a Linux expert around
the whole time, and has free time to tweak their new gadget for
days before they can start using it?? And you know what, I don't
want my mom or any users for that matter to know about what
a _distribution actually is_. Users expect to google for some
tools, go to a site, download a program ("xy for Linux") and use
it with the less hassle and impact on a system. It's amazing how
the Linux community didn't address this so far, and the only
place to get apps from is some central repository specific to
distros (and no, normal users don't want to add some cryptic
lines to the list of repositories). Part of this is caused by
the "dll hell" on Linux and lack of standard interfaces and
a self-contained "app" package. The benefits of the current
systems are clear, but this is wholly favoring server and/or
expert users working on specific distros. Anyhow I'm not
really into discussing this, but for sure Linux just lost one
user over XP because of the above attitude. Unfortunately OS X
was not an option due to price in this specific case.
</OFF>
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
