Hi Przemek,
1. Why I cannot execute this simple scrpit in MacOSX port:
#!/usr/bin/hbrun
proc main()
alert( "Hello World!!!" )
return
I have big internet shop application which with hundreds
CGI harbour scripts and it does not work with MacOSX.
This should work regardless of our static vs. dynlib issue.
So it's off topic.
I'm getting (with a private built hbrun which works):
---
Error BASE/9995 Corruption detected: HB_HRBRUN
Called from HB_HRBRUN(0)
Called from _APPMAIN(0)
---
Maybe something obvious from my side, this is the first
time I tried hbrun this way on any platform.
Also, I have an OSX port of my apps running/building fine
without any need to install stuff in /opt /usr or any other
such non-user locations, or setup envvar or do any global
configuration whatsoever. So the issue is really only hbrun,
hbtest and hbmk behavior. [ None of these is needed for my
project. ]
The fact that you are using Harbour in very limited way like
in Windows it does not mean that you have rights to force
such usage also for other users.
Some facts please. Denying me isn't one.
That's true, but if we provide binaries, I'm not sure there
is a point to limit its usage by using it as a showcase or
to target some other academic goals, or try to replicate
customs from other systems.
I do not agree. You both are thinking only about your current needs.
I want to be able to write Harbour applications as scripts or
binaries and distribute them in system friendly packages like
RPM or DEB. It means that I need Harbour installed in known
for OS and package manager way so dependencies will be check
automatically and if necessary user can download also Harbour
shared libraries or whole compiler and install them in his
system. F.e. I can write new bittorent client as Harbour
application. We do not have to build binaries but we have to
create system where such binaries are easy to create.
Future needs aside, it's not working now.
I couldn't care less if there was however Harbour
packages distributed for OS X, but _they should work
out of the box_. A simple .zip file distribution should
also work out of the box, and if you want to create
such complicated dependency check or installer, or
MacPorts packages so be it, but the default install
(the only one we currently seem to have), should also
work out of the box, without additional trickery, sudo,
envvars, copying, you name it, and current package is
essentially a .zip file.
If you think that whole Harbour future should be reduced to
port your own Clipper applications to different OS-es then we
do not need it at all. Most of core developers have sufficient
knowledge to make their own customized Harbour builds and adopt
his source to them. If you want to see somewhere Harbour as
popular language used to write different type of applications
then we _MUST_ create support for OS friendly installation
which will keep some basic rules between platforms or we
will have serious problems with portability.
First of all it's not about me, but as I estimate
most users downloading our sf.net OSX package. Please
don't try to make it personal and "dumb it down" to
my presumed (by you) ignorance and/or strict personal needs.
I'm talking about './hbmk hello.prg' not working,
'./hbrun' not working and './hbtest' not working.
[ my app doesn't use either hbmk, hbrun or hbtest,
nor .dylibs for that matter, so it's not about my app.
Sad to see however how all Linux users seem to deny
the fact that 3rd party apps may exist, and installation
of these should be possible for normal human beings.
BTW my app seems to be a perfectly usual fat client
application, it seems such apps are common on Linux
and OS X systems too. If this is "personal" or unusual
for Harbour to support, maybe I should really look
elsewhere for the proper tool, maybe you're right. ]
MacOSX native installer is IMHO a must. Just like we should have
BSD ports. There is a big place for Harbour users to help us in
making Harbour more popular so it will be added to official
distributions.
And here I really want to ask all Harbour MacOSX users to participate
in this job to create it. Sorry but here I cannot help. I do not even
know what MacOSX uses as package manager, what is the official
location
policy, how it supports dependencies, etc.
I see you don't believe me, or you didn't read my
prev messages, so I'll stop adding more to the above.
Just read my previous mails. [ -> there is no native
"package manager". ]
You seem to insist on something you don't know much about.
[ I'm talking about OSX. For BSD I have no idea, but
at first it seems like an OS with a wholly different
target audience and a lot different concept on the
UI/usability level. Agreed it would be nice to see
native Harbour package for it. ]
Shared library are simply a MUST. I moved Mac OSX status to "fully
supported development platform" in my company only last week after I
got them working.
No one said otherwise. The question is: why we want to push
this for hbrun, hbtest and hbmk default.
hbtest is not final user application and it's not necessary to
distribute it. hbrun is final user application and it has to be
synced with harbour shared library installed in given OS.
The easiest way is linking it with this library.
It also needs strict location so it cannot be moved to any other
place in official releases just like Harbour shared library so
I do not see what you want to win by forcing static linking.
You will only create bigger binaries.
Given OS? Harbour isn't part of OSX, and I assume it won't
be for some time.
I want to win that when if anyone goes to /bin dir and types
'./hbrun' it actually works, instead of complaining about
missing lib and crashing. The other thing I want is that if
someone goes to /bin dir and types './hbmk hello.prg'
the resulting hello binary would actually work, instead
of crashing, and some would have to find that he needs
-static to make it work.
So far it seems, the fix doesn't create any harm besides
raising disk space requirement by about 2MB.
So far none could say a single argument why -shared
is useful for the above three. (in OS X)
Just like you are presenting only your limited by Windows point
of view without any other argument then I want to make it in
such way because I like it, I used to do it in Windows and
it's enough for me personally.
Try OS X once, I'm not talking about Windows.
Anyhow since you didn't really added anything to my
concerns, just belittling my abilities / standpoint and
painting it as "Windows" and personal, I must assume the
silence means some or all concerns are valid, platform
aside.
Viktor, do it what you only want with MacOSX builds.
I wish you great success.
I do not use MacOSX so it's not a problem for me. When I will
have to use it then for my own personal use I'll create custom
Harbour builds compatible with other environments quite fast.
The only one problem I can see is that I will have to distribute
alternative harbour shared library and hbrun for MacOSX what
can be problem for final users but for sure I'll start with
creating native packages for Harbour installation to reduce it.
Shared library is untouched, so I'm not sure why you
need to build your own. Maybe you'll want to distribute
alternative hbrun binary, which will use some preinstalled
harbour.dylibs on your target systems.
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
