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 > blocked by few users. they should stay core functionality-wise, but by using a loading mechanism of a kind, they should be separately packageable. gtwxc is probably a better example: core, functionality-wise? definitely. but it also has a huge dependency-list many might not be willing to pull. > > a couple of cycles more at application startup, yes, but we are not on > > z80 cp/m anymore ;). the upside is that you get consistent libharbour > > with controllable dependencies (why exactly should i install this 1.5 > > meg worth of libslang onto a pos machine with 4 megs of flash > > otherwise using curses for it's character cell display? why should i > > install 60 megs worth of x junk onto this server that only runs > > przemek's latest "dbf server"? linux people tend to think this way ;), > > and, at times, some of these points actually make sense). > > Fine with me. Although we need to keep a certain > amount of features to stay C5.2 compatible a provide > a common framework for Harbour apps. So such tripping > needs should stop at one point. certainly. but i'm still not talking *stripping* functionality, i'm talking *separating alternatives*. here's a question leading to philosophical depths. with regard to gt drivers, how would you define "c52 compatibility"? i'm quite sure the answer is quite close to "it needs to be able to output stuff". but does it matter where to? by the very virtue of being multi-platform, the *only* possible common denominator is gtnul (no, not even pca or friends - what if there's no "terminal-ish" output of any kind? ok, cgi might still fit. damn. :)). behold, back at square one ;) but then, i'm not against having say, pca and cgi in libhb. they don't need extra dependencies, and this whole thing is about controlling dependencies. > I can just encourage others to join up. to me this thread has already grew tentacles into many directions that i can't really follow it anymore ;) maybe it'd be time to kill it, wait for przemek to read through it, and start new threads on specific subtopics. -- [-] mkdir /nonexistent _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
