> 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 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. Sorry, but I don't see it as core 'functionality-wise'. For core it's enough to provide one working GT _per platform_, to have basic functionality and C5.x compatibility, the rest is extra. The whole point of GTs is that they are replaceable and extendable by anyone. It's not satanic to provide GTs from outside core, even if they are maintained/developed by us. See GTALLEG, GTWVG, GTQTC, they are examples for that. AFAIU the only reason they are still in core, is that some users (most notably Lorenzo and Przemek) are needing these to be part of core harbour dynlib. They also need other extra libs as part of "core" harbour dynlib. This IMO defeats the point of harbour dynlib, since it contains arbitrary elements, and it's used a flexible container for whatever some users may require for their final app. Such thing is okay if done locally (and probably using some distinctive name for such customized harbour dynlib), but for sure not acceptable for mainstream Harbour. Maybe since now there is the already mentioned undocumented way to create customized Harbour dynlibs, this specific issue is no more. The remaining showstopper is missing dynamic build support for such non-core libs. If that's solved, we may easily detach gtsln, gtcrs and gtxwc from core, and handle them as regular (but first class) contrib citizens. Dynamic loading of replaceable components is a very good idea, both for GTs and RDDs. (although IMO not a requirement for anything we discuss here) >>> 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*. To me it looks the same thing. If there are alternatives we will have alternative "frameworks", which to me doesn't look like a very good idea when talking about a language. For sure, GTs and RDDs are replaceable, so strictly we only need to provide the basics (what was available in C5.x). > 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, If it supports a "full screen" type of output, it's IMO okay. > 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 ;) STD, CGI and PCA are not enough for C5.x compatibility. > 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. Yes, they should be std components. >> 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. Okay. To me so far there are these important issues to solve: - Building dynamic lib variant of contribs (and versioning them) - Building executables in contribs - Moving elements from core to contrib, which have external dependencies (gtsln, gtcrs, gtxwc). - Switching to hbmk2 as build tool for contrib area. - Draw the dependency tree for whole Harbour SVN Brgds, Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
