On Thu, 19 Feb 2009, Szak�ts Viktor wrote: Hi Viktor,
> 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. Now in Linux is 100% predictable - GCC is hardcoded as the only one choice :-( and it's necessary to use HB_COMPILER envvar. BTW -cc=<compiler> option will be also usable feature. > > 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. There is one difference between compiler and make wrapper output. hbmk.prg output I need only once when I set new environment. hbcompiler output I need each time when I'm compiling source code which I modified so for me any non compiler messages are only unnecessary noice. Thanks for the -trace hint. > > 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. -n is not necessary and never was. Many people does not use it and have source code which cannot be compiled with this switch so it cannot be enabled by default. Otherwise they still will have to use harbour executable directly. You can try with hbmk script: // t.prg ? "Hello World!!!" hbmk t && ./t > All unprocessed hbmk options are passed down to harbour, > including -gc, -gh, -D, -I, -undef. The above cannot be true because you have to also set at least -I<incDir>. > 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? I'm really sorry but I do not understand what you are talking about. Current hbmk2.prg behavior is different then the one you suggest that exists so I do not know what I should answer and were is a mistake. > > 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. hbmk2.prg should not make any modifications in *.a parameters but pass them to GCC as is because GCC uses in different way .a archive passed directly then -l<libname> option. In the 1-st case for GCC it's only archive with object files which can have any name and can contain the path, f.e.: gcc ... mydir/myobjs.a in the second case its library which have to be located in one of system library paths (or specified by -L option) and need name which confirms platform dependen't naming convention. In most of case it 'lib' prefix and valid sufix ( .a, .so, .dll, .sl, ... ) The link precedence and rules used to overload symbols are also different. Sometimes this difference is important if you want to overload some library functions, f.e. customized getsys in Harbour core code but also some system libraries. To make things more complicated it also depends on -Wl,--start-group / -Wl,--end-group options and used LD. > > 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. See above. > > 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). MinGW and Linux. > 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. The rules are very simple: libraries are scanned for necessary dependence but after scanning it LD does not return to this library and begins to scan next one. If next library contains references to symbols which exist in previous one and was not necessary so far then you have to repeat the previous library after currently scanned one. library grouping creates a set of libraries in which LD returns to previous ones so you do not have to repeat them. Doubling library list is also not real solution in all cases. You can easy create situation when it's necessary to repeat the same library 3, 4 or more times. > > 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? The above is the only one really working solution to replicate Clipper behavior and using as startup symbol 1-st linked function. Such functionality can be implemented correctly only by linker. Here we are trying to make it but because hbmk is not real linker then it's implemented in such hackish way. Of course we can define MAIN() as official startup symbol and remove HB_FS_FIRST support from Windows compiler but it also has some bad side effect. I know few programmers which never use -n switch and have source code like: proc1.prg ? "hello" proc2.prg ... and create different binaries from them choosing different 1-st .prg module. > > 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. yes, and the conclusion was that we can remove it when we will have hb* tool which can set information about 1-st symbol for HVM at link time. If you do not want to extract this symbol from source code or object files then as alternative you can enable in compiler setting HB_FS_FIRST only for one compiled file (the 1-st one) so we will have only one symbol registered in HVM with this flag. > > 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. I do not see any problem here. If I do not use any compiler functions then this library will be ignored at link time. I think that it will be also good to add few contrib libraries like hbct or hbmzip to default library list though it's not strictly necessary. best regards, Przemek _______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
