Just some quick reaction, I have to go now.
and HB_ETC_INSTALL or HB_CNF_INSTALL.
What is the difference between ETC and CNF?
If possible IMO we should not differentiate between
types of config files.
These are my propositions for our new envvar name.
Chose one of them. Personally I preffer the 1-st one.
I'd also prefer ETC.
/lib/
<native_harbour_libraries>
[/<addon_harbour_lib>/
<native_addon_libraries>]
[/<platform>/<cc>/
<platform_cc_libraries>]
I suppose 'contrib' counts as 'addon'.
No, I was thinking about 3-rd party packages which may use many
libraries.
Contrib libraries only in some chosen cases if for some reasons we
decide
they should be separated.
I think it would go rather sooner than later as it starts
to become a problem to manage collisions and it's an important
step towards making contribs fully independent from core and
each other.
Please also note that such subdirectory exists in include.
That's also needed, so it's good.
I do not think that people will like to update existing code and
modify
paths in #include directives but for new 3-rd party / add-on libraries
it seems to be very interesting proposition which allows to resolve
possible name conflicts by using directory with library name in
included
files, i.e. instead of:
#include <header.ch>
user can use:
#include <lib/header.ch>
or use -I switch to give higher priority to some alternative files
overloading our own ones.
This is also good, but I was thinking about something a little
different. When using hbmk2, it's now possible to refer to a given
"addon" (or contrib), via its .hbc file. Now in this .hbc file
there are settings which automatically setup required additional
lib and inc paths for that given component.
It's possible to setup simple .hbc search rules, so that they
are automatically found if placed according to some rules.
It works quite beautifully on non-*nix, but it doesn't when
libs/headers/docs are scattered around the system to
different base dirs.
Basically I'm looking for a way to implement something similar,
but for *nix systems.
Think of one contrib or addon as a "Harbour package" with libs,
headers, docs, examples, whatnot. Something like we have now
under /contrib/*/ dirs. It would be nice to handle them as one
package even in 'localized' form. Or at least provide it as an
option.
IMO and if system rules allow it, we should put native
libs also under plat/cc structure, since generally speaking
we may support multiple compilers with incompatible lib formats
(like watcom and gcc, or anything else in the future).
Plus there must a plat/cc structure also below each addon.
I do not think it's necessary. The default platform libraries always
have to exists and shared libraries from this dir have to be linked
with system library directory so we can store them without plat/cc
what
also nicely shows which binaries are platform native ones.
Please also remember that /<platform>/<cc>/ is only some type of
proposition not suggested form because it's not enough. In some cases
it will be necessary to use sth different, i.e. I can have only
linux/gcc
builds but using different ABI or CPUs. The problem is how to bound
such
It's called build name (HB_BUILD_NAME), and can be added as a 3rd
level above platform / compiler. It doesn't change fundamentals.
We can give a somewhat more distinctive name though.
different configurations with hbmk2. For me ideal situation will be
single
parameter which allows me to chose library subdirectory and hbmk.cfg
file,
I think for most users the best would be if they'd only choose the
target 'platform / compiler / name' and hbmk2 would automatically
know where to look for libs for that specific target.
i.e. working on FreeBSD I'm using -arch=linux-x86_64 and hbmk2 sets
default library directory to <pref>/lib/linux-x86_64/ and then looks
in this directory for hbmk.cfg file to read default configuration.
FHS allows to store some type of configuration/data files used in
readonly mode in 'lib' directories.
That part is okay, but for me the notion of "native" isn't
something I like. In hbmk2 I don't really want to deal with what
is native and handle it differently than any other targets.
It creates all sorts of problems. (f.e. you have to move around
libs when copying a Harbour installation to another system,
or after you've upgraded your system to another ABI, f.e from
32-bit to 64-bit, given that 32-bit exes would otherwise still
run on 64-bit - as on Darwin f.e.)
We should also consider multi-host builds (similar to watcom compiler),
where we provide tools for multiple ABI or platforms installed on
one system. In this case which set of libs should be selected
as "native" ones? and how non-native tools would be able to decide
where to find those libs?
Note that such multi-host build is something I plan for
non-*nix, so we should possible try to support it on non-*nix.
I can even imagine a watcom-like layout which just works on
multiple operating systems if shared from a network drive. Here
work means it can run on multiples OSes and it can create
targets for all those targets. The key here is layout of the
libs.
So, unless it's not outright illegal on *nix systems, a generic
layout, which is independent from the actual "native" build and
without exceptions would be IMO much better.
The shard library naming convention
===================================
@ - softlink
* - hardlink
@<pref><name><epoc>.<ext> ->
@<pref><name><epoc>.<ext>.<major> ->
@<pref><name><epoc>.<ext>.<major>.<minor> ->
*<pref><name><epoc>.<ext>.<major>.<minor>.<rev>
<pref> is library name prefix,
'lib' in supported by Harbour *nix systems
<name> is base name, 'harbour' in our case
<epoc> is used to mark new or alternative branches, we are using
'mt' to mark alternative libraries with MT support.
<ext> is library extension,
'dylib' in Darwin,
'sl' in HP-UX,
'so' in others.
<major>, <minor>, <rev> - version numbers (i.e. 2.0.0 for current
SVN).
i.e.:
@libharbour.so ->
@libharbour.so.2 ->
@libharbour.so.2.0 ->
*libharbour.so.2.0.0
Real/suggested usage in supported *nixes:
Linux, Solaris, Haiku, NetBSD:
@<pref><name><epoc>.<ext> -> *
@<pref><name><epoc>.<ext>.<major> ->
*<pref><name><epoc>.<ext>.<major>.<minor>.<rev>
FreeBSD (some packages use Linux like form):
@<pref><name><epoc>.<ext> ->
*<pref><name><epoc>.<ext>.<major>
OpenBsd:
*<pref><name><epoc>.<ext>.<major>.<minor>
Darwin???
On darwin the current naming seems to be the accepted one,
although some libs use '-' to separate name form version no.
[ I've just browsed my /usr/lib dir for above conclusion,
so I don't know what's the official standpoint here, anyway
I'd assumed the extension is fixed. ]
Thanks for the info, so it's in form like:
@<pref><name><epoc>.<ext> ->
@<pref><name><epoc>.<major>.<ext> ->
@<pref><name><epoc>.<major>.<minor>.<ext> ->
*<pref><name><epoc>.<major>.<minor>.<rev>.<ext>
Yes.
which is not compatible with other *nixes.
Possible, but they keep standard extensions, which makes sense.
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
