Hi Przemek,
> 1. the C compiler auto detection should be extended to use also
> compiler used to compile Harbour.
> This is peace of code I was using from my hb-tools.prg:
>
> if empty( s_hb_compiler )
> cEnv := getEnv( "HB_COMPILER" )
> if !empty( cEnv )
> s_hb_compiler := cEnv
> else
> cEnv := hb_compiler()
> if ( "Borland" $ cEnv .or. "CodeGear" $ cEnv ) .and. ;
> isExecutable( s_hb_ccprefix + "bcc32"
> )
> s_hb_compiler := "bcc32"
> elseif "DJGPP" $ cEnv .and. isExecutable( s_hb_ccprefix + "gcc"
> )
> s_hb_compiler := "djgpp"
> elseif "MinGW" $ cEnv .and. isExecutable( s_hb_ccprefix + "gcc"
> )
> s_hb_compiler := "mingw"
> elseif "GNU C++" $ cEnv .and. isExecutable( s_hb_ccprefix +
> "g++" )
> s_hb_compiler := "g++"
> elseif "GNU C" $ cEnv .and. isExecutable( s_hb_ccprefix + "gcc"
> )
> s_hb_compiler := "gcc"
> elseif "Watcom C++" $ cEnv .and. isExecutable( s_hb_ccprefix +
> "wpp386" )
> s_hb_compiler := "wpp386"
> elseif "Watcom C" $ cEnv .and. isExecutable( s_hb_ccprefix +
> "wcc386" )
> s_hb_compiler := "wcc386"
> elseif "(XCC)" $ cEnv .and. isExecutable( s_hb_ccprefix + "xcc"
> )
> s_hb_compiler := "xcc"
> elseif "Pelles ISO C" $ cEnv .and. isExecutable( s_hb_ccprefix +
> "pocc" )
> s_hb_compiler := "pocc"
> elseif "Digital Mars" $ cEnv .and. isExecutable( s_hb_ccprefix +
> "dmc" )
> s_hb_compiler := "dmc"
> elseif "Microsoft Visual C" $ cEnv .and. isExecutable(
> s_hb_ccprefix + "cl" )
> s_hb_compiler := "msvc"
> endif
> endif
> endif
I intentionally created a fully platform neutral source and
executable (except two minor exceptions). So that an hbmk.exe
created with one compiler can easily be used to build with
any other compiler. It creates a cleaner situation. To make
things clean I also avoided __PLATFORM__ macros, this
is also important to create cross builds in the future. All in
all, exact same code runs on platforms to keep things in hand.
Your idea could be used to prioritize path searches
(specifically the hbmk.exe builder compiler would be
searched first, then the rest), thus possibly helping users
with multiple compilers setup in parallel, and we can
also make autodetection faster for typical cases. I don't
want to abuse this feature too much, as I fear it makes
hbmk detection behaviour less predictable, since we're
using a not very well visible information to bend functionality.
/* in few cases compiler can be used only with single platform so we
> * can always set it here overloading any auto detections
> */
> switch s_hb_compiler
> case "mingw"
> case "mingwce"
> case "bcc32"
> case "xcc"
> case "pocc"
> case "dmc"
> case "msvc"
> s_hb_arch := "win"
> exit
> case "djgpp"
> s_hb_arch := "dos"
> exit
> endswitch
Good idea, I'll do this.
> 2. install dir auto detection should be updated.
> In general we have two version of installation:
> a)
> <basdir>/bin
> <basdir>/include
> <basdir>/lib
> b)
> <basdir>/bin
> <basdir>/include/harbour
> <basdir>/lib/harbour
> so I was using this code:
>
> if !empty( s_hb_hbexe )
> hb_FNameSplit( s_hb_hbexe, @cBinPath )
> if right( cBinPath, 1 ) $ hb_osPathDelimiters()
> cBinPath := left( cBinPath, len( cBinPath ) - 1 )
> endif
> hb_FNameSplit( cBinPath, @cPath, @cName )
> if lower( cName ) == "bin"
> if !right( cPath, 1 ) $ hb_osPathDelimiters()
> cPath += hb_osPathSeparator()
> endif
> if hb_dirExists( cPath + "lib" ) .and. hb_dirExists( cPath +
> "include" )
> if isLib( "hbvm", cPath + "lib" ) .and. ;
> hb_fileExists( cPath + "include" + hb_osPathSeparator()
> + "hbvm.h" )
> s_hb_bindir := cBinPath
> s_hb_libdir := cPath + "lib"
> s_hb_incdir := cPath + "include"
> elseif isLib( "hbvm", cPath + "lib" + hb_osPathSeparator()
> + ;
> "harbour" ) .and. ;
> hb_fileExists( cPath + "include" +
> hb_osPathSeparator() + ;
> "harbour" + hb_osPathSeparator() +
> "hbvm.h" )
> s_hb_bindir := cBinPath
> s_hb_libdir := cPath + "lib" + hb_osPathSeparator() +
> "harbour"
> s_hb_incdir := cPath + "include" + hb_osPathSeparator()
> + "harbour"
> endif
> endif
> endif
> endif
>
>
> static function isLib( cLib, cPath )
> return hb_fileExists( iif( cPath == NIL, s_hb_libdir, cPath ) + ;
> hb_osPathSeparator() + ;
> s_hb_libpfx + cLib + s_hb_libext )
Okay.
>
>
>
> 3. in *nixes GTCGI have to be used as GT driver in hbmk.prg
> otherwise output from external command is lost. Probably
> it should be default also for all other platforms.
Okay.
> 4. Such tool should be as invisible as possible so it should not
> any additional information until not explicitly requested by
> some switch, f.e. -verbose or sth like that to not mix the
> default output from executed compilers.
> It will be good to have additional verbose level in which
> executed command are shown before running compiler application
> to verify final results, f.e. options included by -bldflags
We have -trace to show all commands on screen, and -q to
turn off all informational output and logo. Now it's pretty
much in sync the Harbour compiler, I suppose it'd be used
to replace harbour executable calls, so similar behaviour
is okay. I've also left in some informational output because
we're at the beginning and it helps everyone to find out
what's happening, myself included, so it's partially for
"debugging". Some of those "autodetected this/that"
messages can certainly be made an option using a -info
switch with defaults off. I'll look into that. Verbosity
levels aren't too self-explanatory so let's try with -q, -info,
-trace. I've added -info to my TODO list for now.
> 5. non of Harbour compiler options ( -n -q -w -es2, ...) should
> be enabled by default except the options necessary to compile
> the code: -I<HarbourIncludeDir>, -D<crossBuildDefines>,
> -undef:<crossBuildDefines> and of course -gc[0-3] to force .c
> output but only if user does not specify other form, f.e. -gh.
Only -n is active. Without it, it isn't possible to create
a running executable, so IMO it should be default, unless
we want to use this tool for some other purposes. -q0 is
the other default to hide output. No other Harbour options
are active.
All unprocessed hbmk options are passed down to harbour,
including -gc, -gh, -D, -I, -undef.
>From your words it seems we intend to use this tools
for completely other purposes, so maybe we will want to
add some special modes of operation. I can only guess
what is the scenario you use this (part of a higher level
make system, for larger projects), and since we already
have -cc, -cmp options (and we could have a -lnk, but
couldn't figure the essence of it), maybe we could tie some
defaults you mention to these modes. F.e.:
-cc, -cmp, -lnk could automatically start in -q mode,
with no -n Harbour option, you get the idea. However,
I'd like to keep hbmk for the normal users wanting to
create an exe out of a few prg in manual mode with
presets targeting easy of use.
What do you think?
> 6. -bldflags should be probably divided into C flags and .prg
> flags. User may use completely different .prg flags then the ones
> we used to build Harbour but need C flags which can be necessary
> to create valid binaries.
Okay.
> It will be also good to add automatic support for inheriting some
> C flags we know that are always necessary to create valid binaries,
> f.e. -m32/-m64 on some platforms which can create 32 or 64 bit
> binaries. For GCC I was always using this flags:
> if s_hb_cc == "gcc" .or. s_hb_cc == "g++"
> if "-mlp64" $ s_hb_bldflags
> s_hb_cc_opt -= " -mlp64"
> elseif "-mlp32" $ s_hb_bldflags
> s_hb_cc_opt -= " -mlp32"
> elseif "-m64" $ s_hb_bldflags
> s_hb_cc_opt -= " -m64"
> elseif "-m32" $ s_hb_bldflags
> s_hb_cc_opt -= " -m32"
> endif
> if "-fPIC" $ s_hb_bldflags
> s_hb_cc_opt -= " -fPIC"
> elseif "-fpic" $ s_hb_bldflags
> s_hb_cc_opt -= " -fpic"
> endif
> endif
Good, first I'll add the flag separation for inherited flags,
then it'd be much better if you'd add these to hbmk2.prg.
I'll probably make some mistakes.
> 7. output file name auto detection should respect the compilation
> mode, f.e. hbmk -cmp a.prg it should generate a.{o,obj} not 'a'
> or 'a.exe'
Ok.
> 8. When -l<libname> gcc option is used then <libname> should
> not contain prefix (lib) and extension (.so,.dll,.a)
hbmk does pass the stripped lib name to gcc -l option
already. The extension is already stripped (all of them,
maybe that's too harsh?). So if I understand you correctly
the 'lib' prefix should be stripped, too? In that case, isn't
that dangerous for libnames like "liblibcurl.a" when the
user supplies libcurl, we will have an invalid name.
> 9. We should have support for passing object archives (.a) in
> link file list and then pass it to GCC without -l parameter.
> Using 'mylib.a' and '-lmylib' as GCC parameters has different
> meaning so mylib.a should not be converted to -lmylib but simply
> passed to GCC as is.
I have to think about this one. Should be done, no question,
but I'd like to better understand. What the difference between a
mylib.a as object archive and a mylib.a as lib? Should these
non-lib .a files be supported through .hbp files? We will need
a separate option for it then.
> 10. In GCC builds on platforms which support
> -Wl,--start-group <HARBOUR_LIBS> -Wl,--end-group
> (linux, mingw) we should use it to not replicate libraries with
> cross bindings.
> BTW current library list is not well ordered so it's not possible
> to create some binaries, f.e. try hbmk hbrun.prg in some GCC builds.
> It has to be updated for platforms which does not support above
> library grouping.
I was thinking about this, but didn't reach this topic yet.
-Wl seems easy to add, but I don't know which platforms
support it and which not (mingw does support it for sure).
May I let you do the reordering? I've spend lots of time
trying to figure it, but couldn't find the mechanism, so
I've settled with the first which was doable without full
rewrite and also worked for my own tests.
> 11. There is no support for automatic main function detection in GCC
> builds. This code extracts 1-st function name from the 1-st linked
> file in my hb-tools.prg. It can receive the name of .c file generated
> from .prg file or .o file name but in such case it works only for
> gcc/g++ based compilers (it uses nm tool).
Thanks for the code. Questions 1:
What exactly are we solving here? Forgive my ignorance,
but for the whole lifespan of Harbour I've never needed
anything like this, maybe because I've always used
-n + MAIN() (and -n1 in libs).
Question 2: Could we find a solution which doesn't
need such hacks?
> when we will have fully functional hbmk.prg then we can change
> the startup code and replace current -n1 and default support
> for HB_FS_FIRST. HB_FS_FIRST will be generated only by new explicit
> switch which will be used by hbmk for 1-st file only.
I'm a bit lost here. In autumn we've discussed once
some possibilities for improvement here, to remove
the -n1 switches, I guess you talk about the same.
Then we've agreed on moving in on direction.
> 12. hbdebug and hbcplr libraries are not part of Harbour shared library
> and always should be added as static libraries even when harbour
> shared library is used
Okay, I'll add hbdebug in shared mode. As for hbcplr, I'm not sure of the
legal situation here and it wasn't there in hbmk.bat.
> 13. the -o can point also to directory name not only file. hbmk.prg
> should respect it and check the type of destination. Some C compilers
> does not support -o as directory name so they will need different
> calling if more then one .c file is passed in single command, f.e.
> explicitly used chdir. Harbour compiler support -o as directory name
> if the last character is path separator, f.e.:
> harbour test.prg -ooutdir/
Okay, thought about it already.
> it would be very nice if hbmk.prg can use -o<dir> also for temporary
> C files.
It's probably too late, but I can't get this right now :)
Thanks for your suggestions, let's continue with
some remaining points from above, and I'll try to
implement the rest of the features in the meanwhile.
Brgds,
Viktor
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
