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
...
which will keep some basic rules between platforms or we
will have serious problems with portability.
I think we have 3 different situations:
1 - Linux
well known and accepted standards like RPM and DEB and most of the
dependences are available within the "official" repository ( f.e. zip,
openssl, gd, postgresql, mysqll and so on )
Fine and really smooth.
But: What about (desktop) apps / components not included in
any official repository? (Google Earth, VBOX VM Additions,
certain drivers)
2 - Win
here we have a standard way of install ( setup.exe ) but things get
complicated since we support many different C compilers and there is
no a simple way to get dependences
Most current packages takes the route to package everything
they need to a dir and ship that dir via std setup or simple
.zip file. Starts to become pretty clean for those apps
that provide a .zip too. Also see the "portable app" movement.
3 - OSX
the tool that create packages comes with the OS but it's not easy to
get dependences and there very few ( 2 ) users, also there are 2 arch
ppc and Intel
Latter is no problem at all with Universal Binaries. It simply
means a longer build process on your side and a bigger disk
footprint on the user side.
Which is the tool you're referring to?
Win it's completely different if a developer want to use msys/mingw (
like me ) or other "native" compilers like MSVC xyx, BCC xyz, ....
It's different where to get dependences and how to build programs (
hb* scripts vs batch files )
I think we should separate the issues of building an
app and installing an app. Anyhow the build tools indeed
influence the final dependencies. For my case (if anyone
is interested) MinGW built stuff needs an extra MSVCRT.DLL,
while MSVC needs nothing. The app is dependent on openssl,
libssh, libcurl, libharu, libpng. All linked as static
libs to lessen any client-side problems.
Borland C is really problematic and it's not so much
supported for all above packages. So it's usually more
pain to build them, or to find anything prebuilt.
Building above stuff is even an exercise for MSVC and
MinGW. In contrary to Harbour f.e., shipped make files
needs to be manually tweaked for most packages.
In OSX is even more complicated by the fact that we've only 2
developers and at least for me with a very basic knowledge of the dev
tools.
Now it seems we're missing the main point:
Why should a non-Clipper developer choose Harbour instead of PHP,
Python, Java, .Net or whatever else? and how can Harbour attract other
Linux, OSX, Win developers?
Can we imagine an OSX developer that choose Harbour without a GUI?
Can we imagine a web developer that choose Harbour without an Apache
module?
Can we imagine an SQL developer that choose Harbour without an
Oracle module?
I think we ( mostly you ) should define the goals and check where to
find the resources to achieve them. If we're a small group of old
Clipper developers that need to maintain its legacy apps than the goal
was achieved with 1.0 if not it's time to make choices.
Questions are good. Personally I need Harbour to use my
existing code base and to avoid a painful rewrite (which
is pretty moot having been spent more time on Harbour
than a rewrite would have taken probably ;) It's not just
about time.
For new development... dunno how Harbour could make an
impact. It's good, but we cannot count on legacy
developers, plus, quite some parts are missing which are
already there in PHP. Yet the future seems web and server
side.
I hope someone will tell something more positive.
However I'll start to look at the OSX packager and I'll report
Thanks.
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
