On Tue, 22 Sep 2009, Szak�ts Viktor wrote:
Hi,
> 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.
>> /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.
Please also note that such subdirectory exists in include.
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.
> 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
different configurations with hbmk2. For me ideal situation will be single
parameter which allows me to chose library subdirectory and hbmk.cfg file,
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.
>> 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>
which is not compatible with other *nixes.
best regards,
Przemek
_______________________________________________
Harbour mailing list
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
