Re: [Harbour] haiku fallout
On Sun, 20 Sep 2009, Szak�ts Viktor wrote:
[...]
Usually in system installation we have existing structure like:
instpref/bin - with executable files, one of PATH dirs
we should not use any subdirectories here
instpref/lib - with shared libraries, one of system library dirs
we can use subdirectory for static libraries and
it's even suggested to reduce name conflicts
but native shared library have to be in this
localization
instpref/include - with header files, we can and should use subdir
for our own header files
instpref/share/man - with man files - sub dirs with strict meaning and
naming convention. Sometimes it's without share
instpref/man (i.e. in /usr/local)
instpref/share/doc - with non man documentation, we should use subdir
instpref/etc - with configuration files, if necessary it's
possible to use subdirs with the exception to
/usr which stores configuration files in /etc
FHS suggests also to use /etc/opt and /etc/local
for configurations files from /opt /usr/local
For applications which can be globally accessed it's suggested to move
configuration files into '/etc' directory. It helps in creating backups
but also in locating configuration files by other programs bound with
given application, i.e. in our case we may talk about final user
applications compiled by Harbour which may look for some system global
Harbour configuration files, i.e. now /etc/harbour/hb-charmap.def which
is used optionally by some GTs like GTCRS or GTTRM (for details look at
source/rtl/gtcrs/hb-charmap.def, I plan to introduce also hb-keymap.def
and hb-termmap.def for GTTRM what should allow to configure some unknown
for GTTRM terminals by users or system admins) and I would like to keep
/etc/harbour as default global harbour configuration directory though
for packages installed in '/opt' FHS suggests to use '/etc/opt'.
It's not easy to create rules which can follow exactly different
distribution policy so we should give an interface to set each of the
above directory separately. It means that we have to introduce yet
two new envvars for man and configurations files, i.e. HB_MAN_INSTALL
and HB_ETC_INSTALL or HB_CNF_INSTALL.
Building RPM packages we have predefined macros like %{_bindir}, %{_libdir},
%{_includedir}, %{_mandir}, %{_sysconfdir}, %{_defaultdocdir}, ... which
can be used to set our own HB_*_INSTALL variables to suggested system
directories without touching HB_INSTALL_PREFIX so it's not a problem.
We do not use autoconf so we have to chose sth ourselves for 'manual'
installation using only HB_INSTALL_PREFIX. We have to remember also
that at runtime hbmk2 may need to replicate some parts of our detection
logic.
Here are 4 system wide installations which can be used in different
*nixes and try to confirm FHS as close as possible.
'-' means soft link,
1. FHS2.3 compliant localization for add-on applications:
=
/opt/
/harbour/
/bin/
harbour_executable_files
/lib/
native_harbour_libraries
[/addon_harbour_lib/
native_addon_libraries]
[/platform/cc/
platform_cc_libraries]
/include/
harbour_header_files
[/addon_harbour_lib/
addon_header_files]
/share/
/man/
/man1/
harbour_man_pages.1
/doc/
harbour_doc_files_and_dirs
[/addon_harbour_lib/
addon_docs]
/etc - /etc/harbour
/etc/
/harbour/
harbour_config_files
/etc/
/opt/ (if exists)
/harbour - /etc/harbour
if /opt/bin exists then we should create in this directory soft links
to executable files in /opt/harbour/bin
if /opt/lib exists then we should create in this directory soft links
to harbour shared libraries in /opt/harbour/lib
if /opt/man/man1 exists then we should create in this directory soft links
to harbour shared libraries in /opt/harbour/share/man/man1
2. FHS2.3 compliant localization for distribution applications:
===
/usr/
/bin/
harbour_executable_files
/lib/
soft_links_to_native_harbour_shared_libraries
/harbour/
native_harbour_libraries
[/addon_harbour_lib/
[/platform/cc/
platform_cc_libraries]
/include/
Re: [Harbour] haiku fallout
Hi Przemek, 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. /lib/ native_harbour_libraries [/addon_harbour_lib/ native_addon_libraries] [/platform/cc/ platform_cc_libraries] I suppose 'contrib' counts as 'addon'. 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. The shard library naming convention === @ - softlink * - hardlink @prefnameepoc.ext - @prefnameepoc.ext.major - @prefnameepoc.ext.major.minor - *prefnameepoc.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: @prefnameepoc.ext - * @prefnameepoc.ext.major - *prefnameepoc.ext.major.minor.rev FreeBSD (some packages use Linux like form): @prefnameepoc.ext - *prefnameepoc.ext.major OpenBsd: *prefnameepoc.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. ] Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] haiku fallout
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
Re: [Harbour] haiku fallout
On 2009 Sep 21, at 00:07, Przemyslaw Czerpak wrote: On Sun, 20 Sep 2009, Szak�ts Viktor wrote: Here if possible I'd like to see some syncing between *nix and non-*nix. On non-*nix dlls are created in bin dir, while on *nix they are created in lib dir. This isn't too good. It will create series of problems. shared libraries have exectable attribute but they are not normal executable files. It will confuse shell in tab expansion, GPF on unwanted execution, break strict protection rules in some distributions, etc. I think that it's much easier to agree with some conservative admin that you will put into one of PATH directories series of MP3 files with hard rock but without executable and write attribute then single library file with executable attribute and it's not a joke :) :) So it *is* satanic. Not a big problem overall, the main thing here is that all libs should be accessible from lib dir, which is now solved nicely using implibs for remaining (windows) cases. Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
[Harbour] haiku fallout
hi, now with libharbour*.so installed in /boot/common/lib/harbour/, things don't find it. -- [-] mkdir /nonexistent ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] haiku fallout
needs more massaging apparently. I have no opinion on these file placements, so pls just advise what to do, or feel free to patch it the way it's best. Brgds, Viktor On 2009 Sep 20, at 19:37, Tamas TEVESZ wrote: hi, now with libharbour*.so installed in /boot/common/lib/harbour/, things don't find it. -- [-] mkdir /nonexistent ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] haiku fallout
On Sun, 20 Sep 2009, Tamas TEVESZ wrote:
Hi,
now with libharbour*.so installed in /boot/common/lib/harbour/, things
don't find it.
Not now but from the beginning of adding default HAIKU localization
it was installed in:
HB_INSTALL_PREFIX=/boot/common
${HB_INSTALL_PREFIX}/bin/
${HB_INSTALL_PREFIX}/lib/harbour/
${HB_INSTALL_PREFIX}/include/harbour/
In general it's a work in progress and in final version we will have soft
links (just like now in other *nixes) or we will store static and dynamic
libraries in different directories. See recent Viktor's modifications.
We should agree here few things:
1. what is system wide localization and what user customized and how
to detec them.
2. what directory structure we should use for both type of installation
respecting multi C compiler or cross build binaries. We should also
define data directory for Harbour system wide installation. I do not
like current situation that:
druzus:~# ls /usr/bin|wc -l
3213
druzus:~# for f in /usr/bin/*; do [ -x $f ] || echo $f; done
/usr/bin/hbmk.cfg
druzus:~#
storing configuration files in system wide binary directories
is unacceptable for most of distributions.
3. where to put static and shared libraries (now it's possible
to set different localizations) and/or where create soft links.
4. shared library naming convention - now only Darwin build tries to
respect correct version setting in names and links.
5. how to merge binaries for different C compilers and/or different
platforms (cross building) and how user should chose preferable
C compiler or destination platform.
I think we should define it ASAP to reduce number of necessary
modifications for users which tries to follow SVN modifications
and sync his local repositories with SVN quite often.
Meanwhile you can simply add /boot/common/lib/harbour to LIBRARY_PATH
envvar in your HAIKU installation.
best regards,
Przemek
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] haiku fallout
now with libharbour*.so installed in /boot/common/lib/harbour/,
things
don't find it.
Not now but from the beginning of adding default HAIKU localization
it was installed in:
HB_INSTALL_PREFIX=/boot/common
${HB_INSTALL_PREFIX}/bin/
${HB_INSTALL_PREFIX}/lib/harbour/
${HB_INSTALL_PREFIX}/include/harbour/
In general it's a work in progress and in final version we will have
soft
links (just like now in other *nixes) or we will store static and
dynamic
libraries in different directories. See recent Viktor's modifications.
We should agree here few things:
1. what is system wide localization and what user customized and how
to detec them.
Yes.
2. what directory structure we should use for both type of
installation
respecting multi C compiler or cross build binaries. We should also
define data directory for Harbour system wide installation. I do not
like current situation that:
druzus:~# ls /usr/bin|wc -l
3213
druzus:~# for f in /usr/bin/*; do [ -x $f ] || echo $f; done
/usr/bin/hbmk.cfg
druzus:~#
storing configuration files in system wide binary directories
is unacceptable for most of distributions.
Note that hbmk2 already supports several system locations,
so we're free to store it anywhere.
I'd add some more things here:
- where to put 'contrib', 'addon' dirs as separate entities, so that
they don't get mixed in core libs/headers/etc.
- where to put docs, examples.
- where to put INSTALL, Changelog, ERRATA, TODO and COPYING.
3. where to put static and shared libraries (now it's possible
to set different localizations) and/or where create soft links.
Yes.
+1: How to name them. Current naming is more or less unified
for non-*nix, but for *nix we have the darwin world and the
rest, which are different in several ways. Maybe this is normal,
but I'd like to know for sure.
4. shared library naming convention - now only Darwin build tries to
respect correct version setting in names and links.
:) yup, see above.
5. how to merge binaries for different C compilers and/or different
platforms (cross building) and how user should chose preferable
C compiler or destination platform.
Yes, for non-*nix, the system is to use:
bin/arch/comp/*
or
bin/arch/*
for bins.
and
lib/arch/comp/*
for libs.
I think we should define it ASAP to reduce number of necessary
modifications for users which tries to follow SVN modifications
and sync his local repositories with SVN quite often.
Agreed.
Brgds,
Viktor
___
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] haiku fallout
1. what is system wide localization and what user customized and how to detec them. One clean / easy / universal solution is to consider it user customized when it resides inside /home or /Users, and system location if anywhere outside that. 3. where to put static and shared libraries (now it's possible to set different localizations) and/or where create soft links. Here if possible I'd like to see some syncing between *nix and non-*nix. On non-*nix dlls are created in bin dir, while on *nix they are created in lib dir. This isn't too good. So, if there is nothing satanic about it, I'd put *nix dlls also to bin dir, and add links to lib dir. 4. shared library naming convention - now only Darwin build tries to respect correct version setting in names and links. Current situation: harbour[mt]-20-wce-arm - WinCE ARM harbour[mt]-20-wce-mips - WinCE MIPS harbour[mt]-20-wce-sh - WinCE SH harbour[mt]-20-wce - WinCE x86 harbour[mt]-20-os2 - OS/2 harbour[mt]-20 - win harbour[mt]-20-bcc - win x86 (bcc) harbour[mt]-20-x64 - win x64 harbour[mt]-20-ia64 - win ia64 harbour[mt].2.0.0 - darwin harbour[mt].2 - darwin (link) harbour[mt] - darwin (link) harbour[mt]-2.0.0 - non-darwin *nix harbour[mt] - non-darwin *nix (link) harbour[m] - MS-DOS - For one thing, we should IMO only have major+minor ver numbers even on *nixes, since we guarantee binary compatibility between revisions. - We should check whether '.' separate in darwin is a necessity on the platform, if not, it should be switched to '-'. - Maybe we should always add 'win' for win platform, why making it the default? - Maybe we should always add CPU on win platform. x64 will eventually become the standard anyway. - What remains is the major/minor separator. Probably we should switch to '2.0' format on non-*nix too. - Fix darwin/non-darwin links. This would result in something like this: harbour[mt]-2.0-wce-arm - WinCE ARM harbour[mt]-2.0-wce-mips - WinCE MIPS harbour[mt]-2.0-wce-sh - WinCE SH harbour[mt]-2.0-wce-x86 - WinCE x86 harbour[mt]-2.0-os2 - OS/2 harbour[mt]-2.0-win-x86 - win harbour[mt]-2.0-win-x86-bcc - win x86 (bcc) harbour[mt]-2.0-win-x64 - win x64 harbour[mt]-2.0-win-ia64 - win ia64 harbour[mt]-2.0 - *nix harbour[mt]-2 - *nix (link - MAYBE - I can't see its use) harbour[mt] - *nix (link) harbour[m] - MS-DOS The only downside I can see is longish .dll names, but IMO that's not a problem. 5. how to merge binaries for different C compilers and/or different platforms (cross building) and how user should chose preferable C compiler or destination platform. [ touched that in a prev mail ] Brgds, Viktor ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
Re: [Harbour] haiku fallout
On Sun, 20 Sep 2009, Szak�ts Viktor wrote: Here if possible I'd like to see some syncing between *nix and non-*nix. On non-*nix dlls are created in bin dir, while on *nix they are created in lib dir. This isn't too good. It will create series of problems. shared libraries have exectable attribute but they are not normal executable files. It will confuse shell in tab expansion, GPF on unwanted execution, break strict protection rules in some distributions, etc. I think that it's much easier to agree with some conservative admin that you will put into one of PATH directories series of MP3 files with hard rock but without executable and write attribute then single library file with executable attribute and it's not a joke :) best regards, Przemek ___ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
