On Thu, 19 Feb 2009, Szak�ts Viktor wrote:
Hi,
> I know, but this isn't a Linux tool :) For Linux it isn't hardcoded,
> just the default is set to gcc. You can set it just like for hbmk
> script HB_COMPILER=gpp|owatcom. The new command
For hbmk script I do not have to set anything because it's build
dynamically in install phase from user settings.
> line switch is fine and I wanted to add it, but under the name of
> -comp= (-cc is occupied already for mode setting). Also -arch=
> should be added. I'll do these.
I think that here we have yet another mistake. Probably someone send
you some very old hbcc description. In RPMs and in doc/howtobld.txt
we have:
,---------------------------------------------------------------------
| "hbcc" is a wrapper to the C compiler only. It sets all flags
| and paths necessary to compile .c files which include Harbour header
| files. The result of its work is an object file.
`---------------------------------------------------------------------
> I'll add -info switch which will control currend OutStd()
> messages, these will be kept 'on' until we test hbmk,
> later turned off. -q will disable informational messages
> + logo.
But -q is also harbour compiler switch so I cannot control them
separately.
> > // t.prg
> > ? "Hello World!!!"
> > hbmk t && ./t
> Is this also true on Windows? all compilers? I'd love to
> see it working like this on all platforms/compilers, and in
> this case we can safely remove -n.
It is and always was in the whole [x]Harbour history I remember.
> What about the -n1 situation? Is it possible to add those
> discussed changes?
I think that we should finish one thing 1-st. I have not idea what will
be the final result of hbmk2.prg usage in different platform and for
cross compilation so I'd prefer to leave it as is.
> Which it does, but it was so obvious I didn't include
> in my answer.
It's very hard to guess what is obvious for you.
-n and -q wasn't for me.
Just like this:
TODO: Add support for wildcarded input source.
Only if only one source file is specified.
is obvious technical nonsense for *nix users ;-)
> We had hbcc, hbcmp, hblnk and hbmk scripts so far.
> Now we have hbmk program, which has -cc, -cmp,
> -lnk (not yet committed) switches to emulate the
> above modes, even more, there is autodetection for
> these modes based on argv[0].
Here we should also add something to change path base path
logic detection because link can be in different directories
then hmmk2 binaries. We should add support for passing some
build time switches, f.e. we have to decode HB_PCRE_REGEX
and HB_EXT_ZLIB build time macros to use native platform pcre
and zlib binaries.
Probably hbmk2.prg auto detection logic should be changed.
1. default compile time mode - used by 99% of users which
strictly keep the same platform and C compiler as the
one used to create hbmk2 binaries. It's very seldom
situation when user will want to use harbour.exe/hbmk2.exe
compiled by different C compiler then the one used to compile
harbour libraries. Such situation happens only during cross
compilation. In fact also using different C compiler for the
same platform should be treated as some type of cross compilation
because binary libraries in most of cases cannot be moved between
compilers and even if final executable files can be created then
there is very big chance that it will be corrupted due to difference
in CRTLs. I also do not believe that many users will try to collect
manually final Harbour installation from two different binary builds
and hbmk2.exe will come from the 1-st one and libraries from the second
one. It's unusual situation and any auto detection which will prefer it
will only create more troubles by sporadic wrong compiler detection
due to differences in environment settings.
In this mode hbmk2.prg should fully respect compile time macros
like HB_PCRE_REGEX, HB_EXT_ZLIB, HAVE_GPM_H, etc. It may also
detect default GT driver and not overload it if it's not strictly
necessary though it's minor feature.
2. support for cross compilation where we can chose other then default
C compiler.
In such case it will be also necessary to set different library path
(in few seldom situations maybe also include path), (un)define some
harbour compiler macros using -D/-undef: options, set C compiler prefix
and/or some C compiler options. It will be hard to create full
auto detection for all possible combinations so user will have to
control each setting manually. To make it easier I suggest to intorduce
config file which will have sctions like in .ini file. Each section
will contain full information necessary to pass succesfully cross
compilation, f.e.:
[xmingw]
COMPILER=mingw
CCPREFIX=/usr/local/bin/i386-mingw32-
PRGFLAGS=-D__PLATFORM__WINDOWS -undef:__PLATFORM__UNIX
-undef:__PLATFORM__LINUX
...
such file is easy to edit and it's not necessary to hard code all
information in different make file. It's also easy to copy and update
on different computer for different configuration. It's single file so
setting new environment is much easier. I hate when I have to update
xxx files and I forgot about some of them. After setting user can
easy specify 'xmingw' in some hbmk2 parameter and work with new
environment.
> I only assume the
> real-life purpose of cc/cmp/lnk modes, as I've never
> used or need them, that they are intended to be used
> in make scripts and hbmk to be used manually.
I do not see any reason why we have to hard code such limitation
and forbid users to use hbmk also in make scripts. For me it's the
main job of such tool and I do not expect that we will create make
system comparable to GNU make in the nearest future.
> At least for typical uses. Hence we can tailor the
> verbosity defaults based on the mode of operation
> to make a best fit for typical usage of given mode.
yes.
> [ I may change -cc/-cmp switches to -mode=<mode>
> because -lnk collides with -l switch and it impossible
> to pass lib named 'nk'. ]
Yes, all hbmk switches should be added with careful to not
reduce possible collisions with parameters of executed compilers.
best regards,
Przemek
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
