On Wed, 25 Feb 2009, Szak�ts Viktor wrote:
Hi,
> To continue:
> I like this dir to look like this (on all platforms ideally, of course with
> applying extensions):
> ---
> hbmk.cfg
> harbour.dll
> harbourmt.dll
> harbour.exe
> hbdoc.exe
> hbi18n.exe
> hbmk.exe
> hbpp.exe
> hbrun.exe
> hbtest.exe
> ---
With the exception to hbmk.cfg which cannot be stored in binary
directory in system wide installation due to distribution policy
in most of *nixes so in *nix builds hbmk should look for this file
in:
<hbmkdir>
<hbmkdir>/../etc/harbour
<hbmkdir>/../etc // "/harbour/" is part of hbmkdir
/etc/harbour
/etc // "/harbour/" is part of hbmkdir
In *nixes it's also good pratcie to look for users customized
settings, f.e.:
${HOME}/.harbour/
> I'd like to get agreement on this from the list, because I'm
> willing to do it but unless the group can agree to do it I wouldn't
> want to force this. Anyhow it would be great to Harbour itself,
> it's maintainability and accessibility for users (= there is no point
> in having all these features if only Harbour experts are able to
> create a build or compile a test app). It would certainly help if
> we could all somehow look past our _strict personal insistence_
> on keeping compatibility with every small detail (with regards
> to build environment), we're skilled enough to make some
> modifications on the local systems I guess (I had done quite
> many recently on mine).
The basic functionality for native compilation seems to work but I haven't
made deeper tests so maybe I missed sth. I'll try to make such test in the
weekend. So far I noticed that -static is default mode in *nix builds
and -fullstatic does not work at all so always dynamic applications are
created and only harbour static libraries are used.
Harbour does not have any chance to be ever part of default Windows
installation but it has big chance to be part of different open source
based systems but we have to respect the official distribution rules
so in *nixes shared linking should be default.
The second problem is support for cross compilation. Here I haven't
even try to make any tests. In the last days hbmk2 was changed too
often to even start them. Just simply I do not know how will look
the final base code. I still think that auto detection should be based
on compiler used to compile hbmk2.prg and other configurations should
be done on user requests. Any automatic compiler detection by PATH
search for me can be only source of problems because Harbour libraries
are not binary compatible when compiled by different compilers. In few
cases they are (f.e. POCC/XCC) but probably no one of us knows if CRTLs
are fully compatible and it's safe to mix libraries compiled by different
C compilers. Unfortunately simple test and answer "is running for me"
is not enough because problems can be hidden very deeply, f.e. some
memory corruptions which can be exploited only in some seldom cases.
So such autodetection can cause really unpredictible results.
It will be good if linker refuse creating final binaries so user will
notice it and fix the environment settings but in the worst case the
application can be linked and executed but will not work correctly.
I'm finding it as very danger situation especially in Windows where
user can have many C compilers and small modifications in environment
settings f.e. after installing new C compiler may cause that wrong
binaries which cannot be easy tested will be delivered to customers.
For me the Harbour/hbmk2 build time C compiler should have the highest
priority.
> Don't be mistaken this isn't some kind of personal need
> for me, since I can build Harbour and use Harbour in all
> environments, but all feedbacks (not only from the list, but
> from potential users), tells me that we could do a lot to make
> Harbour better in these areas. And I've dedicated my last 2-3
> weeks of my free time to address these things.
> Some things I'd like to clean:
> - non-GNU make files. [.dll creation works for the most part in GNU-make
> now.]
I do not know what you are asking for.
> - harbour.cfg + Harbour -go option: hbmk2 is here as a better solution.
I do not have clear opinion about it. I do not use it so for me it can
be dropped though if Harbour will be default part of some OS distributions
then such mechanism can be easy used for binding with default C compiler,
f.e. also with -pipe option to eliminate temporary files.
BTW I haven't asked about it before but it will be good if hbmk2 can
create intermediate .c file in some temporary location and not use
<baseprgdir>/<baseprgname>.c files. In the past I lost few times some
files when by mistake I used the same name for .prg and .c files.
> - hb* helper scripts, batches: confuse users, and doesn't add functionality.
We can remove them in some longer terms, f.e. after few weeks of hbmk2
testing. But please do not remove the internal logic from hbmk2 code
which recognize them so anyone who will want to use it can create own
links.
> - hb-mkslib compatibility name: not widely used, easy to add locally for
> those who depend on it, otherwise it
> just creates ambiguity.
The above is IMHO only your personal feeling. hb-mkslib exists for nearly
6 years in [x]Harbour world and AFAIK is quite often used. Anyhow we can
remove it in the future probably together with linkes to hbmk2.
> - gcc specific hbmk script: hbmk2 is meant to replace it.
yes, when it will be tested and will support existing functionality.
F.e. RPMs with WIN32 and WINCE cross builds will work with hbmk2 just
like know works with hbmk.
I do not like this idea but for my own use I will create my own Harbour
builds so it's not a problem for me.
> - rename hbmk2 to hbmk.
AFAIK it's the goal :-)
But non of the above is development stopper so this are minor thinks
which can be made by any of us in less then 15 minutes. The important
is existing hbmk2 functionality.
best regards,
Przemek
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
