Re: [Harbour] Re: To Viktor about openSuse rpm
so it is controlled by some heuristics mechanism, i couldn't quickly find where this is. i suppose it has to do with known sysloc paths. building the deb n stuff it looks like: ! HB_BIN_INSTALL: /usr/bin ! HB_LIB_INSTALL: /usr/lib/harbour ! HB_INC_INSTALL: /usr/include/harbour ! HB_DOC_INSTALL: /usr/share/doc/harbour ! HB_INSTALL_PREFIX automatically set to: /usr/local this might be it. install locations are explicitly set, but setting install_prefix doesn't take these into account, and is also set to a non-system loc, which in turn somehow controls dyn builds. it is generally not acceptable to ship packages like this. especially if there is a shared lib, then it shall be used by applications. Good point. I think the above is wrong because it tries to override make system, while it simply should set HB_INSTALL_PREFIX to /usr and let it set the rest automatically. In case there is a problem with these settings it should be fixed in global.mk. Or HB_DYN_INSTALL should be also set. Should be checked why HB_INSTALL_PREFIX is used behind the scenes directly. management, network management, dbf drivers, full stop). should the compiler and headers, and contrib/rddads be installed in this case? hardly. Well, standalone apps built using Harbour and part of Harbour package can be like that (like hbrun), but I think this projects primary goal is to build a compiler, and even hbrun may need .ch header and even such dbf server is most likely to have a client side, which will in turn need the compiler. What you describe fits the 'harbour-tool' category, which is fine. So to reiterate, maybe a harbour-dynlibs package, and a harbour-staticlibs package are justified, but this to me feels like breaking the principle of least surprise. what is in harbour-dynlibs would be called libharbour-dev by convention (watch me cheat, it would be called harbour-devel in rpm-land :), but the principle of separation still is the same); similarly, harbour-statislibs would be harbour-dev; although i agree that the fact that there is a runtime and also a compiler is provided by hb makes this a little special. Please note that I used these names just like as an indication of their content, not as final names, final names should be whatever they be, and I'm not interested in the details too much to be honest, there are much better candidates to decide on that :) (to me it's total mess: see. harbour-dev vs harbour-devel to start with :/) maybe so that libharbour has the shared objects, libharbour-dev has the static archives and the headers. are ch needed when only using an app linked against libharbour? if yes, and for example hbrun needs .ch are needed by harbour, hbrun and hbmk2. that, tools can be made to depend on -dev. harbour would then have the compiler, pp and the rest of the gang. libhb is the base of all stuff. hbrun pulls libhb-dev, harbour pulls in hbrun (and lets hbrun implicitly pull libhb-dev). what existing package might be similar to this that could be studied for some inspiration? i can't really think of any now. I had python and ruby in mind, but I can't guarantee they are similar enough, for sure their 'contrib' solution is worth to see, I'm not sure about the core. Since they are meant as separate entities, we should have the option to untie they versioning from core anytime. Until they live inside the same repository, we should sync their version to core. it just dawned on me that there also is hbide, which for the moment lives in contrib yes, but is shortly (for an arbitrary definition of short) is expected to enter core, so i think we also should take a harbour-ide package into consideration right at the beginning. i'd rather prefer it not be made part of dev. I think such things should be always packaged separately, they may have pretty large requirements, and there is no point in forcing anyone to install qt libs just to use Harbour. Same goes for anything else executable which currently resides in contrib or examples, like hbnetiosrv. As a general rule of thumb I wouldn't add fat to core unless absolutely necessary, but rather grow a vivid circle of addons as separate packages. Also notice that current GNU make system doesn't support building of executable in the contrib area. Maybe it would work, but I certainly haven't tried it, and I bet it would need some polishing here and there. I have also the notion to move out all contribs from GNU Make territory and make them build with hbmk2. This would nicely solve the dynlib creation problem, plus few other ones (more lose integration with core, easily detachable, good test bed for hbmk2, etc). This system is already implemented for the /examples tree. As for the expected _set of content_, I agree we should have a standard defined, and it's defined well already. It's roughly everything inside /src except compiler. We
Re: [Harbour] Re: To Viktor about openSuse rpm
I will start over later today. I want just to say that I did not use HB_*_INSTALL overrides when building rpm... It is true that I used HB_*_INSTAL in a previous make; make install style compilation that I used to check which files were compiled but it was in another terminal session The RPMs created are: harbour-2.0.1-devsus112.i586.rpm harbour-allegro-2.0.1-devsus112.i586.rpm harbour-cairo-2.0.1-devsus112.i586.rpm harbour-contrib-2.0.1-devsus112.i586.rpm harbour-curl-2.0.1-devsus112.i586.rpm harbour-firebird-2.0.1-devsus112.i586.rpm harbour-gd-2.0.1-devsus112.i586.rpm harbour-lib-2.0.1-devsus112.i586.rpm harbour-mysql-2.0.1-devsus112.i586.rpm harbour-odbc-2.0.1-devsus112.i586.rpm harbour-pgsql-2.0.1-devsus112.i586.rpm harbour-qt-2.0.1-devsus112.i586.rpm harbour-static-2.0.1-devsus112.i586.rpm harbour-lib contains the .so libraries harbour-static contains the .a libraries It seems that some .a libraries (like hbcplr.a) are needed also for linking the .so libraries I don't know if this is an Harbour requirement or hbmk2 requirement Francesco ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: To Viktor about openSuse rpm
Hi, I will start over later today. I want just to say that I did not use HB_*_INSTALL overrides when building rpm... It is true that I used HB_*_INSTAL in a previous make; make install style compilation that I used to check which files were compiled but it was in another terminal session Okay, thank you. The RPMs created are: harbour-2.0.1-devsus112.i586.rpm harbour-allegro-2.0.1-devsus112.i586.rpm harbour-cairo-2.0.1-devsus112.i586.rpm harbour-contrib-2.0.1-devsus112.i586.rpm harbour-curl-2.0.1-devsus112.i586.rpm harbour-firebird-2.0.1-devsus112.i586.rpm harbour-gd-2.0.1-devsus112.i586.rpm harbour-lib-2.0.1-devsus112.i586.rpm harbour-mysql-2.0.1-devsus112.i586.rpm harbour-odbc-2.0.1-devsus112.i586.rpm harbour-pgsql-2.0.1-devsus112.i586.rpm harbour-qt-2.0.1-devsus112.i586.rpm harbour-static-2.0.1-devsus112.i586.rpm harbour-lib contains the .so libraries harbour-static contains the .a libraries To me this practice looks rather strange. Unless there is good reason to split Harbour core into main/lib/static packages, IMO they should be packaged together. I don't why it was implemented this way, and I hope someone will clarify. It seems that some .a libraries (like hbcplr.a) are needed also for linking the .so libraries I don't know if this is an Harbour requirement or hbmk2 requirement hbmk2 has no extra requirements over Harbour. Its only job is to serve Harbour requirements as is. You're right that hbcplr.a may be required even when .so is used. This is normal, as the compiler (hbcplr) is licensed differently, and not part of .so. This means that to build certain tools (like hbrun, hbmk2 itself), both static and dynamic libs should be installed. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: To Viktor about openSuse rpm
On Sun, 3 Jan 2010, francesco perillo wrote: harbour-static contains the .a libraries doesn't suse name these kinds of packages -devel, like any rpm system with good manners does? -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: To Viktor about openSuse rpm
On Sun, Jan 3, 2010 at 11:20 AM, Tamas TEVESZ i...@extreme.hu wrote: On Sun, 3 Jan 2010, francesco perillo wrote: harbour-static contains the .a libraries doesn't suse name these kinds of packages -devel, like any rpm system with good manners does? Well, I will check with other compiler packages ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: To Viktor about openSuse rpm
On Sun, 3 Jan 2010, francesco perillo wrote: On Sun, Jan 3, 2010 at 11:20 AM, Tamas TEVESZ i...@extreme.hu wrote: On Sun, 3 Jan 2010, francesco perillo wrote: harbour-static contains the .a libraries doesn't suse name these kinds of packages -devel, like any rpm system with good manners does? Well, I will check with other compiler packages you should be checking the library packages instead. -static means a completely different thing. -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: To Viktor about openSuse rpm
-devel packages include files that permit to extend core functionalities... python-devel: Include Files and Libraries Mandatory for Building Python Modules I don't agree to have a harbour-devel.. .gcc doesn't have a -devel... it has a compiler package taht includes almost everything... From what I understand, harbour-lib MUST be installed on all systems that must run shared compiled Harbour programs. core and static are instead for programmers-only... I'd merge these two because static is required anyway if you compile a shared library ! Francesco ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: To Viktor about openSuse rpm
From what I understand, harbour-lib MUST be installed on all systems that must run shared compiled Harbour programs. core and static are instead for programmers-only... I'd merge these two because static is required anyway if you compile a shared library ! I agree to merge. hbmk2 indeed refers to static hbcplr even when not strictly required to build the app, it's simply present in lib list. This is required to present similar behavior in both static and dynamic hbmk2 build modes. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: To Viktor about openSuse rpm
On Sun, 3 Jan 2010, francesco perillo wrote: francesco, honestly this is not intended as an offence, far be from it, but there are established standards and policies for packaging, which you are not to reinvent, override or outsmart, but to follow. opensuse has some nice documentation on packaging at http://en.opensuse.org/Packaging, especially for the currently relevant topic of libraries at http://en.opensuse.org/Packaging/Shared_Library_Packaging_Policy note it says packaging policy, not packaging suggestions. proper packaging is much more complicated and tricky business than most of you can even begin to imagine, and it most certainly isn't just lets shovel a metric shitload of files into an rpm (or deb, or anything else, for that matter) container and call it a day. as things stand now, as far as i can tell (this is a long shot, and a premature statement from my side, but hey) the upstream build system and upstream procedures aren't even able to support proper packaging. again, do not take this the wrong way, but it really is a much more complicated matter than most of you seem to think. -- [-] mkdir /nonexistent ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: To Viktor about openSuse rpm
note it says packaging policy, not packaging suggestions. proper packaging is much more complicated and tricky business than most of you can even begin to imagine, and it most certainly isn't just lets shovel a metric shitload of files into an rpm (or deb, or anything else, for that matter) container and call it a day. I have a pending commit, which merges core + lib + static rpms into one. Is this okay? We can rename it to anything, although I have to wonder about these policies... This policy is OpenSUSE specific. Now if each distro has its own policy (and why not, I bet they have), we will have some fun waste of time trying to satisfy all of them. I'm naiv, but I'd think there must exist some RPM / DEB level policies which are idealistically in sync with downstream distro policies. If there are such policies, first we should try to stick to them. So to sum it up, I propose these priorities when it comes to cleanup up our RPM / DEB support: 1. general *nix policies (SUS) 2. general Linux policies (LSB) 3. RPM / DEB packaging level policies 4. distro specific policies Some contradictions are expected, f.e. LSB doesn't support DEB, anyway it's no question we must support it. as things stand now, as far as i can tell (this is a long shot, and a premature statement from my side, but hey) the upstream build system and upstream procedures aren't even able to support proper packaging. What is exactly missing? Watching the chaos and total _enduser_ unfriendliness in the Linux world, I'm a little bit worried now about the price to pay to become part of this system. For a start, Linux was unable to reach a common packaging method in 15 years. (No wonder it doesn't catch up on the desktop) Seems we will be forced to use some tools which will try to pull us to become Linux specific, instead of being portable/multiplatform. We should try to avoid this. Worst case we can maintain patches which implement these whatever requirements of each distribution we may want to support. Brgds, Viktor ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: To Viktor about openSuse rpm
Hi Tamas, I'm not offended since I'm not the original author of the .spec files... I just wanted to help build the RPMs on Suse (both openSuse and SLE[D|S]) since I have several running systems at work and at home that I can use to do such builds. I was trying to understand how these builds worked and found some inconsistencies... and I reported them... opensuse has some nice documentation on packaging at http://en.opensuse.org/Packaging, especially for the currently relevant topic of libraries at http://en.opensuse.org/Packaging/Shared_Library_Packaging_Policy I will read them later... but I miss some infos on Harbour internals, libraries and dependencies I can't help too much... Francesco ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] Re: To Viktor about openSuse rpm
On Sun, 3 Jan 2010, Viktor Szakáts wrote:
most things below are just scratching the problem-surface, and
definitely need more eyes.
I have a pending commit, which merges core + lib + static
rpms into one. Is this okay?
definitely not.
i think that the proper splitting is something very close to this (as
i'm primarily familiar with deb, that's what i base the following
upon, but the general principle applies with most every distro, and to
some extent ports, pkgsrc, and whatever other packaging method there
is):
harbour-utils - hbrun, maybe hbtest
libharbour$shlib_version - libharbour{mt,}.so.x.y.z
libharbour-dev - *.h, *.api, libharbour{mt,}.so (symlink to .x.y.z)
harbour - harbour, hbmk2, *.ch, other stuff that are directly used
when compiling prg to native code
harbour-doc - stuff in doc/
libharbour-foo - a foo component with the foo.so.x.y.z
libharbour-foo-dev - headers for this foo.so.x.y.z, and foo.so (link
to foo.so.x.y.z)
of course with carefully crafted dependencies between these, where
internal dependencies between tools and stuff may further change the
scene.
as you can see, there is a lot of the above that is not there in the
build system.
the first problem is a consistent shared library versioning policy.
currently the so version is stuck to the harbour version number, which
is suboptimal. it has had the same version number for quite some time,
with api and maybe abi changes too, this is bad karma. there needs to
be a procedure stating if you change abi in an incompatible way, bump
major; if you change abi in a compatible way, bump minor; if unsure,
bump, or something along these lines.
this is a strict prerequisite for any libharbour package, which in
turn is a strict prerequisite for (other, 3rd party) stuff written in
harbour entering any distro (which i suppose is an implicit goal,
otherwise there's no point in harbour itself entering any distro).
this only covers libharbour, and does not even begin to scratch the
stuff that is currently only shipped in static archives. it seems to
be customary not to make shared versions of these; i haven't yet
figured out whether this is good or bad (i can reason either case,
though :).
yes, this detaches libharbour version from the actual harbour version,
but it also makes it possible (with some extra tweaks i s'pose) to
have several libharbour versions installed, which is good for example
if there is a harbour-2.0 package with the release version, and a
harbour-be (for bleeding edge) version updated regularly, thus
making it possible for a developer (harbour user, who develops in
harbour, but who does not develop harbour) to have a stable
development environment as well as be able to test new features,
follow new features (maybe in a separate branch in her application),
and also report bugs with the development version of harbour.
libharbour also needs some baseline functionality. what this means is
that no matter where, on what system, in what environment, etc etc, is
a libharbour.so.x.y.z is generated, any other libharbour.so with the
same x.y.z version generated on any other system in any other
environment need to have at least a well-defined common ground (call
it core functionality), ideally be the same. what this actually
means is up for definition (eg. what rdds, what gts, etc etc).
optional (everything the above does not cover) is to be supplied in
separate {libraries, archives, ...} maybe by libharbour dlopening them
on demand, or whatever.
consider this: i have application `foobar', it uses
libharbour-4.3.11, and it crashes when i look to the left. the
backtrace says `system has been recalled'. currently basically
there's no way to tell what actually *is* in libharbour-4.3.11, making
debugging in email (which *will* happen, when we're there) nigh
impossible. mix and match this with the currently non-existing
consistent shlib versions, and it quickly translates to hm,
libharbour-4.3.11. we have absolutely no idea what it might be.
then there's the question of packaging the contrib stuff, possibly
creating packages that support cross-compiling (the picture starts to
get blurry now -- see, you don't, for example, package gtwvw for a
native package, but you do for a cross-compile environment).
then there's the question of (again) packaging the contrib stuff - do
we want a separate package for each (i can reason pro and con against
either), or do we want to group them by some attributes (i can reason
pro and con against either) (though my preference is this latter), ...
at this point i literally got tired of citing the issues, as in i
really need a coffee, but i'm pretty much certain that by now everyone
sees that it is _rather a complicated issue_.
We can rename it to anything, although I have to wonder about
these policies... This policy is OpenSUSE specific. Now if each
distro has its own policy (and why not, I bet they have), we
will have some fun waste
Re: [Harbour] Re: To Viktor about openSuse rpm
definitely not.
i think that the proper splitting is something very close to this (as
i'm primarily familiar with deb, that's what i base the following
upon, but the general principle applies with most every distro, and to
some extent ports, pkgsrc, and whatever other packaging method there
is):
harbour-utils - hbrun, maybe hbtest
libharbour$shlib_version - libharbour{mt,}.so.x.y.z
libharbour-dev - *.h, *.api, libharbour{mt,}.so (symlink to .x.y.z)
harbour - harbour, hbmk2, *.ch, other stuff that are directly used
when compiling prg to native code
harbour-doc - stuff in doc/
libharbour-foo - a foo component with the foo.so.x.y.z
libharbour-foo-dev - headers for this foo.so.x.y.z, and foo.so (link
to foo.so.x.y.z)
What is the point of having 'harbour' package, when
nothing useful can be done with it? In any case, hbmk2
needs to be moved to utils since it requires libs to
work.
Then what is the point of having hbrun without dynamic
libs, when hbrun is built as shared binary in certain
situations, so it cannot work without Harbour dynamic
lib also.
I think the ultimate difference between Harbour and
regular 'lib' packages, is that in Harbour there is
not much point in having a dev packages, as development
consists of building final apps in 99.99% of cases,
and not building something else with the help of Harbour
headers.
harbour compiler executable can do very little thing
by itself, as far as real-life usage goes.
Here comes to mind, that maybe we should also list
C compiler tools as dependency, because without C
compiler, Harbour is again unusable.
of course with carefully crafted dependencies between these, where
internal dependencies between tools and stuff may further change the
scene.
as you can see, there is a lot of the above that is not there in the
build system.
the first problem is a consistent shared library versioning policy.
currently the so version is stuck to the harbour version number, which
is suboptimal. it has had the same version number for quite some time,
with api and maybe abi changes too, this is bad karma. there needs to
We've been in development stage. Version in increased
by each major release, and we promise to keep compatibility
between minor releases only. Emphasis on _release_. Current
SVN, beta, or rc isn't a release.
be a procedure stating if you change abi in an incompatible way, bump
major; if you change abi in a compatible way, bump minor; if unsure,
bump, or something along these lines.
We have that, see above.
this only covers libharbour, and does not even begin to scratch the
stuff that is currently only shipped in static archives. it seems to
be customary not to make shared versions of these; i haven't yet
figured out whether this is good or bad (i can reason either case,
though :).
Yes, shared lib creation for contribs is not implemented
(yet?).
yes, this detaches libharbour version from the actual harbour version,
but it also makes it possible (with some extra tweaks i s'pose) to
have several libharbour versions installed, which is good for example
if there is a harbour-2.0 package with the release version, and a
harbour-be (for bleeding edge) version updated regularly, thus
making it possible for a developer (harbour user, who develops in
harbour, but who does not develop harbour) to have a stable
development environment as well as be able to test new features,
follow new features (maybe in a separate branch in her application),
and also report bugs with the development version of harbour.
This is only possible in pure dynamic world I guess.
libharbour also needs some baseline functionality. what this means is
that no matter where, on what system, in what environment, etc etc, is
a libharbour.so.x.y.z is generated, any other libharbour.so with the
same x.y.z version generated on any other system in any other
environment need to have at least a well-defined common ground (call
it core functionality), ideally be the same. what this actually
means is up for definition (eg. what rdds, what gts, etc etc).
I'd personally define get Harbour lib version as the only
core functionality which we promise to be compatible across
all version. I don't see a point in limiting ourselves, as it
would just effectively halt development and force us to
concentrate on nothing else, but compatibility.
As for the expected _set of content_, I agree we should have
a standard defined, and it's defined well already.
It's roughly everything inside /src except compiler. We call
this Harbour core. [ The only place this can be violated
is an extra undocumented build option to mash together core
dynamic lib with contribs libs, something I've been arguing
against recently. ]
Above this are contribs, which are independent of each
other and independent of core, utilizing official Harbour
APIs only, plus they may have extra external dependencies.
optional
Re: [Harbour] Re: To Viktor about openSuse rpm
On Sun, 3 Jan 2010, Viktor Szakáts wrote:
harbour-utils - hbrun, maybe hbtest
libharbour$shlib_version - libharbour{mt,}.so.x.y.z
libharbour-dev - *.h, *.api, libharbour{mt,}.so (symlink to .x.y.z)
harbour - harbour, hbmk2, *.ch, other stuff that are directly used
when compiling prg to native code
harbour-doc - stuff in doc/
libharbour-foo - a foo component with the foo.so.x.y.z
libharbour-foo-dev - headers for this foo.so.x.y.z, and foo.so (link
to foo.so.x.y.z)
What is the point of having 'harbour' package, when
nothing useful can be done with it? In any case, hbmk2
needs to be moved to utils since it requires libs to
work.
naturally there are dependencies between them, also external deps as
needed.
Then what is the point of having hbrun without dynamic
libs, when hbrun is built as shared binary in certain
situations, so it cannot work without Harbour dynamic
lib also.
i might be misunderstanding something, but this seems to be untrue. i
have a hbrun binary that (to a certain extent) chugs along nicely,
without any trace of a dynamic libharbour (or anything else harbour)
being around anywhere.
I think the ultimate difference between Harbour and
regular 'lib' packages, is that in Harbour there is
not much point in having a dev packages, as development
consists of building final apps in 99.99% of cases,
and not building something else with the help of Harbour
headers.
hbrun's script interpreter mode is the prime example of the contrary.
also imagine przemek coming up with (arbitrary example) an ads-like
dbf server, which relies on and only relies on libhb (file
management, network management, dbf drivers, full stop). should the
compiler and headers, and contrib/rddads be installed in this case?
hardly.
harbour compiler executable can do very little thing
by itself, as far as real-life usage goes.
Here comes to mind, that maybe we should also list
C compiler tools as dependency, because without C
compiler, Harbour is again unusable.
yes, of course. i deliberately didn't go into such details for fear of
being lost in them.
the first problem is a consistent shared library versioning policy.
currently the so version is stuck to the harbour version number, which
is suboptimal. it has had the same version number for quite some time,
with api and maybe abi changes too, this is bad karma. there needs to
We've been in development stage. Version in increased
by each major release, and we promise to keep compatibility
between minor releases only. Emphasis on _release_. Current
SVN, beta, or rc isn't a release.
ok, i accept that. i still think that bumping as changes go would be
better, but i accept that.
this only covers libharbour, and does not even begin to scratch the
stuff that is currently only shipped in static archives. it seems to
be customary not to make shared versions of these; i haven't yet
figured out whether this is good or bad (i can reason either case,
though :).
Yes, shared lib creation for contribs is not implemented
(yet?).
i feel they also should be, but this also raises libver questions. do
they live a separate life, or do we go with one and only one version
for the whole shebang?
have several libharbour versions installed, which is good for example
if there is a harbour-2.0 package with the release version, and a
harbour-be (for bleeding edge) version updated regularly, thus
making it possible for a developer (harbour user, who develops in
harbour, but who does not develop harbour) to have a stable
development environment as well as be able to test new features,
follow new features (maybe in a separate branch in her application),
and also report bugs with the development version of harbour.
This is only possible in pure dynamic world I guess.
certainly. in a static world, none of this thread applies at all. in
that case, any harbour package is only used by a developer
(application developer writing prg code, producing executables that
only (dyn)link against stuff outside harbour), thus making the whole
proper package idea moot at best, as any package becomes just a
convenience container, for which the current setup is ok. won't ever
enter any distro, but if no end-user is ever to use it, then it
doesn't matter either.
libharbour also needs some baseline functionality. what this means is
that no matter where, on what system, in what environment, etc etc, is
a libharbour.so.x.y.z is generated, any other libharbour.so with the
same x.y.z version generated on any other system in any other
environment need to have at least a well-defined common ground (call
it core functionality), ideally be the same. what this actually
means is up for definition (eg. what rdds, what gts, etc etc).
I'd personally define get Harbour lib version as the only
core
Re: [Harbour] Re: To Viktor about openSuse rpm
What is the point of having 'harbour' package, when nothing useful can be done with it? In any case, hbmk2 needs to be moved to utils since it requires libs to work. naturally there are dependencies between them, also external deps as needed. Then what is the point of having hbrun without dynamic libs, when hbrun is built as shared binary in certain situations, so it cannot work without Harbour dynamic lib also. i might be misunderstanding something, but this seems to be untrue. i have a hbrun binary that (to a certain extent) chugs along nicely, without any trace of a dynamic libharbour (or anything else harbour) being around anywhere. It depends on the setup. For cases where Harbour is built to be installed in system locations, the binaries are built against the shared lib. I think the ultimate difference between Harbour and regular 'lib' packages, is that in Harbour there is not much point in having a dev packages, as development consists of building final apps in 99.99% of cases, and not building something else with the help of Harbour headers. hbrun's script interpreter mode is the prime example of the contrary. also imagine przemek coming up with (arbitrary example) an ads-like dbf server, which relies on and only relies on libhb (file That's true, although hbrun is _not_ part of the default core package we're talking about. hbrun however, requires shared lib. management, network management, dbf drivers, full stop). should the compiler and headers, and contrib/rddads be installed in this case? hardly. Well, standalone apps built using Harbour and part of Harbour package can be like that (like hbrun), but I think this projects primary goal is to build a compiler, and even hbrun may need .ch header and even such dbf server is most likely to have a client side, which will in turn need the compiler. What you describe fits the 'harbour-tool' category, which is fine. So to reiterate, maybe a harbour-dynlibs package, and a harbour-staticlibs package are justified, but only as long as these are always pulled by harbour-core package. harbour-tools package would only pull harbour-dynlibs. this only covers libharbour, and does not even begin to scratch the stuff that is currently only shipped in static archives. it seems to be customary not to make shared versions of these; i haven't yet figured out whether this is good or bad (i can reason either case, though :). Yes, shared lib creation for contribs is not implemented (yet?). i feel they also should be, but this also raises libver questions. do they live a separate life, or do we go with one and only one version for the whole shebang? Since they are meant as separate entities, we should have the option to untie they versioning from core anytime. Until they live inside the same repository, we should sync their version to core. libharbour also needs some baseline functionality. what this means is that no matter where, on what system, in what environment, etc etc, is a libharbour.so.x.y.z is generated, any other libharbour.so with the same x.y.z version generated on any other system in any other environment need to have at least a well-defined common ground (call it core functionality), ideally be the same. what this actually means is up for definition (eg. what rdds, what gts, etc etc). I'd personally define get Harbour lib version as the only core functionality which we promise to be compatible across all version. I don't see a point in limiting ourselves, as it no, no. i'm not talking versions, i'm talking instances. both you and i have r13450 sources. you build on your system, i build on mine. can you be sure we have a libharbour.so with the exact same functionality? no, you can't. The only thing we can guarantee is that 2.0.0 (release) will be compatible with 2.0.2 (release), but we don't guarantee that 3.0.0 will be compatible with any of them. Revision-level compatibility isn't achievable, and it would be insane to pursue such goal. It's simply unmanageable. btw, is this api or abi compatibility that is promised? Ideally both. would just effectively halt development and force us to concentrate on nothing else, but compatibility. i fail to see why, but let's not get lost in this detail. i'll just accept your point. That would mean every SVN revision is a final release. Who would guarantee this promise? Or, who would try to document all the changes in between each revision which happens to break some compatibility details? I think here on the dev lists users are too much given the impression that each SVN revision is a release, because these revisions are most of the time stable. But: they are not. As for the expected _set of content_, I agree we should have a standard defined, and it's defined well already. It's roughly everything inside /src except compiler. We call this flat out can not be
Re: [Harbour] Re: To Viktor about openSuse rpm
On Sun, 3 Jan 2010, Viktor Szakáts wrote: Then what is the point of having hbrun without dynamic libs, when hbrun is built as shared binary in certain situations, so it cannot work without Harbour dynamic lib also. i might be misunderstanding something, but this seems to be untrue. i have a hbrun binary that (to a certain extent) chugs along nicely, without any trace of a dynamic libharbour (or anything else harbour) being around anywhere. It depends on the setup. For cases where Harbour is built to be installed in system locations, the binaries are built against the shared lib. so it is controlled by some heuristics mechanism, i couldn't quickly find where this is. i suppose it has to do with known sysloc paths. building the deb n stuff it looks like: ! HB_BIN_INSTALL: /usr/bin ! HB_LIB_INSTALL: /usr/lib/harbour ! HB_INC_INSTALL: /usr/include/harbour ! HB_DOC_INSTALL: /usr/share/doc/harbour ! HB_INSTALL_PREFIX automatically set to: /usr/local this might be it. install locations are explicitly set, but setting install_prefix doesn't take these into account, and is also set to a non-system loc, which in turn somehow controls dyn builds. it is generally not acceptable to ship packages like this. especially if there is a shared lib, then it shall be used by applications. I think the ultimate difference between Harbour and regular 'lib' packages, is that in Harbour there is not much point in having a dev packages, as development consists of building final apps in 99.99% of cases, and not building something else with the help of Harbour headers. hbrun's script interpreter mode is the prime example of the contrary. also imagine przemek coming up with (arbitrary example) an ads-like dbf server, which relies on and only relies on libhb (file That's true, although hbrun is _not_ part of the default core package we're talking about. hbrun however, requires shared lib. management, network management, dbf drivers, full stop). should the compiler and headers, and contrib/rddads be installed in this case? hardly. Well, standalone apps built using Harbour and part of Harbour package can be like that (like hbrun), but I think this projects primary goal is to build a compiler, and even hbrun may need .ch header and even such dbf server is most likely to have a client side, which will in turn need the compiler. What you describe fits the 'harbour-tool' category, which is fine. So to reiterate, maybe a harbour-dynlibs package, and a harbour-staticlibs package are justified, but this to me feels like breaking the principle of least surprise. what is in harbour-dynlibs would be called libharbour-dev by convention (watch me cheat, it would be called harbour-devel in rpm-land :), but the principle of separation still is the same); similarly, harbour-statislibs would be harbour-dev; although i agree that the fact that there is a runtime and also a compiler is provided by hb makes this a little special. maybe so that libharbour has the shared objects, libharbour-dev has the static archives and the headers. are ch needed when only using an app linked against libharbour? if yes, and for example hbrun needs that, tools can be made to depend on -dev. harbour would then have the compiler, pp and the rest of the gang. libhb is the base of all stuff. hbrun pulls libhb-dev, harbour pulls in hbrun (and lets hbrun implicitly pull libhb-dev). what existing package might be similar to this that could be studied for some inspiration? i can't really think of any now. only as long as these are always pulled by harbour-core package. harbour-tools package would only pull harbour-dynlibs. i feel they also should be, but this also raises libver questions. do they live a separate life, or do we go with one and only one version for the whole shebang? Since they are meant as separate entities, we should have the option to untie they versioning from core anytime. Until they live inside the same repository, we should sync their version to core. it just dawned on me that there also is hbide, which for the moment lives in contrib yes, but is shortly (for an arbitrary definition of short) is expected to enter core, so i think we also should take a harbour-ide package into consideration right at the beginning. i'd rather prefer it not be made part of dev. As for the expected _set of content_, I agree we should have a standard defined, and it's defined well already. It's roughly everything inside /src except compiler. We call this flat out can not be true ;) if you have slang-dev installed and i don't, you get a libharbour with gtslang, i get one without. same sources, system-dependent result. I you ask me, I wanted to pull out gtcrs and gtsln from inside the core for somewhat similar reasons, but it got
Re: [Harbour] Re: To Viktor about openSuse rpm
I suggest you to start over, and if you still have problems, pls publish your build log so we can see what exactly happened and what settings were used. Brgds, Viktor On 2010 Jan 3, at 03:07, francesco perillo wrote: 3bis) I installed the contrib package where harupdf is but I got another error: contrib/hbhpdf/tests # hbmk2 harupdf.prg hbmk2: Processing local make script: hbmk.hbm hbmk2: Processing configuration: /usr/bin/hbmk.cfg Harbour 2.0.1dev (Rev. 13448) Copyright (c) 1999-2010, http://www.harbour-project.org/ Compiling 'harupdf.prg'... Lines 2246, Functions/Procedures 18 Generating C source output to 'harupdf.c'... Done. /usr/lib/gcc/i586-suse-linux/4.4/../../../../i586-suse-linux/bin/ld: cannot find -llibhpdf collect2: ld returned 1 exit status hbmk2: Error: Running linker. 1 gcc harupdf.o hbmk_cwkl0s.o -Wl,--start-group -lhbhpdf -llibhpdf -lpng -lhbct -lhbcplr -lhbdebug -lharbour -Wl,--end-group -oharupdf -L/usr/lib/harbour 4) I was able to succesfully compile, link and run Qt samples (after installing the Qt package of course, hbide, hbxbp, hbqt) and cairo ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
