Hi Przemek,
> 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. 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 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. > > "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. 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. > > 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 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. What about the -n1 situation? Is it possible to add those discussed changes? > > 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>. Which it does, but it was so obvious I didn't include in my answer. > 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. 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]. 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. 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. [ I may change -cc/-cmp switches to -mode=<mode> because -lnk collides with -l switch and it impossible to pass lib named 'nk'. ] I'll answer to the rest of the message a bit later. Brgs, Viktor > > 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 >
_______________________________________________ Harbour mailing list Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
