Hi Przemek,
> > ---
>
> 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
Yep, .cfg should of course go into proper settings
dir on *nixes. hbmk2 already picks some of these, but
I'll sync it with your list. I'll pbly need help how to install
it in final locations.
> In *nixes it's also good pratcie to look for users customized
> settings, f.e.:
> ${HOME}/.harbour/
I'll add this, thanks for it.
> > 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.
Yes, such things should be corrected. -fullstatic was never thoroughly
tested. Please do more tests. hbmk2 is doing a shared build by default
if Harbour is installed in a system dir, and it's doing a static one by
default if it's just run from any other dir. These defaults can also be
controlled through hbmk.cfg, either by installers or the user.
> 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.
Sorry, only if it's installed in some system locations (Harbour attempts
to detect it, and installers can override). Harbour in
/home/myname/programs/test/harboursvn/... shouldn't try to create
a shared build by default, as it won't work. If the user placed the .so
dir in LD_PATH the shared build can be enabled in hbmk.cfg. Or,
we can even attempt do an autodetection for harbour.so accessibility
and decide accordingly. What do you think?
[ Anyhow I'd like it we consider those ppl who for any reason don't
want to install, just play with Harbour without impacting the system.
Harbour may even be embedded into a larger product. ]
> 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"
hbmk.cfg is storing the host compiler/platform now so what you say can
now enabled without hard-wiring anything to the .exe (which is a big no-no
for Windows apps). Plus, what you say is the default for *nix systems
already. For non-*nix, the host compiler is searched first, so it will be
picked even if multiple compilers are accessible in PATH. We can also
use above hbmk.cfg information in the future, but IMO at this point it's
not
necessary, first let's hear some feedback.
Cross compilation doesn't seem _that_ difficult to me, I've even used
hbmk2 already for such purpose, and all it took was to use a manually
overridden HB_LIB_INSTALL setting. I'm not saying this is enough for
all cases of course, this was an easier one for sure.
In any case, with regards to my proposed cleanup this doesn't seem
to make a difference as we're talking about _new functionality_ (unless
I'm missing something regarding hbmk capabilities), so it can be added
gradually but at least independently of all these.
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.
Please check how it's working now. If we will be having problems,
we can resort to hbmk.cfg COMP/ARCH values.
> > 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.
Shortly this:
del /s make_b32*.*
del /s make_vc*.*
del /s make_gcc*.*
del /s mtpl_b32*.*
del /s mtpl_vc*.*
del /s mtpl_gcc*.*
del /s common.mak
Having multiple (2, three of four depending on how you count it) make
systems creates the worst maintenance nightmare to maintain, support,
test, sync, and _document_. Far from ideal, and give a rough time
for everyone trying to make a build.
> > - 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.
Is it useful enough to keep it? (I don't think so.)
Can we implement similar stuff in hbmk2?
> 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.
I'll add this to the TODO list. It's not clear to me how this could
work with the -hbcc option though.
> > - 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.
I don't plan to do such thing. Probably -hblnk is completely
unnecessary now though, unless I'm missing some functionality it
did. So after I clean some stuff, this option should go, or simply
be ignored (pls tell if this is needed).
> > - 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.
OK.
> > - 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.
Sorry, I've lost this one, could you clarify?
> > - 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.
That's right.
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
