Hi Lorenzo,
The problem is that in Mac OSX there are more arch combinations than
developers :)
For example yesterday I wanted to test the new gtk beta and I followed
the 1,2,3 steps suggested at http://www.gtk-osx.org, It installed like
a charm in perfect OSX style but they simply forgot to mention that it
was only for i386 arch.
Even worse Xcode builds it without any error but the executable simply
did nothing.
Only when I run it from the terminal I see the message "... wrong
platform".
Then I read that "The recommended way to build GTK+ is to use jhbuild"
and I found that it simply download sources from svn and build them.
After a while I got a working gtk env.
Also macports the "standard" way to get 3rd party software simply
downloads and builds from source and install everything in
/opt/local/...
Macports is one (Linux-like) 3rd party solution. [ I try to
not use it, as it adds up a difficult to replicate component
to an otherwise clean system. You need to do sudo/admin, which
I also try to avoid. ]
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. ]
I know we don't agree here but I still think that creating binary
distributions of a multi platform, multi architecture open source
compiler are a waste of time.
I understand that an OpenOffice user don't want to know how to build
it but the knowledge required to build Harbour is the same necessary
to use it.
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.
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.
..
Without it I will have to recompile my applications for user
host. I do not like such improvement ;-)
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.
So far none could say a single argument why -shared
is useful for the above three. (in OS X)
The days of native executables are ended many years ago: both Java and
.Net use intermediate code.
This really doesn't have to do too much with making an
executable standalone or not. There exist standalone
executables for both .NET and Java. Since Harbour has much
less bloat, standalone is pretty much a no brainer here.
The next most important feature for me are the HRLs the "hrb
libraries" and a way to package several hrbs and hrls into a zip and
execute it directly from hbrun.
And an hbrun which can actually run without needing
an install by an admin or other hassles.
Lorenzo can you explain how you are able to use shared libraries
in MacOSX.
I simply use hb-mkslib and set DYLD_LIBRARY_PATH envvars to the
dylibs path.
There is only one small fix in hb-mkslib to do. Here is a snap of
the message:
I don't want to store any temporary paths in
an envvar, nor to modify my environment just to
run a simple hbrun/hbtest.
change -install_name parameter to:
${CCPREFIX}libtool -dynamic -install_name "${BASE}${SLIB_EXT}" \
Check if everything works correctly. If yes then please commit it.
Thanks it was it :)
Since today Mac OS X is a first class citizen in our company.
-------------------------------
After that hbmk -n -shared hello.prg works without any problem.
Fine, but since -shared is the default now, even those
users have to fiddle with this, who wouldn't want.
-shared should be an (non-default) option in OS X.
Brgds,
Viktor
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
