On Wed, 04 Mar 2009, Szak�ts Viktor wrote: Hi,
> > all C parameters are stripped. > > The same is for -hblnk > > All parameters not recognized by hbmk2 should be passed to executed C > > compiler/linker. > Yeah, and this is the point where I feel I cannot help without > turning hbmk2 into something which I didn't plan. It was a > big surprise for me today to realize in xhgtk, that hbcc/hblnk > is accepting _plain raw compiler/linker (?) options_. Besides creating > a big maintainability problem (all the possible clashes with hbmk > options), and an easy way to mess up an internal assumptions > about the compiler / linker state or executed command line > (quite huge problem by itself), it ruins the whole concept of hbmk2, > since instead of giving an abstract interface to the user, it aids > non-portable usage. Even basic C switches aren't compatible > accross compilers, like -I, maybe -D is portable but I'd not be > surprised to find differences. Concept is also ruined because > any kind of source file is currently supported, so what exactly > should happen when using: hbmk2 hello.prg myfunc.c -DMYDEFINE. > Pass -DMYDEFINE to C also? What if we pass some other > misc option: hbmk hello.prg myfunc.c -W4? Linker options are > even scarier. > With hbmk script this of course wasn't a big problem, as it only > had to support gcc. > .hbp files are meant to store such compiler specific options in > cflags=, with filters. I think that now you begin to understand what hb* scripts do and why separation by links was very usable. hbcmp/hbcc/hblnk defines what should be done with parameters. > So, I really don't know what to do here... Maybe we should > support a few generic ones, like -D... I have no idea. Sorry. In the future we may think about cross compiler C settings. I'm finding it very interesting. But now the only one thing which is necessary is simple coping given parameters which are not hbmk2 parameters to executed C compiler or Harbour compiler in -hbcmp mode without guessing what they do. AFAIK hbmk2 does not try to decode all Harbour parameters but simply pass them to Harbour compiler. So why it cannot make the same with C compiler in hbcc and hblnk modes? For sure it will be much better then current silent stripping them. I know about possible name conflicts and that not all parameters can be passed to C compiler because some of them are used as hbmk2 parameters. But if it will be necessary then we can simply add -hbparams=<params> switch. > > There is also minor problem with -o <filename>. > > It does not accept space after -o. It's not a big problem for me > > but on some platforms the space is required and it may confuse > > user who replace 'gcc' calls with 'hbmk2 -hbcc' > I'd like to keep it that way for now, hbmk2 isn't gcc, so I hope > ppl will read the help :) I'd like to resemble to Harbour, which > doesn't need (or accept) the space. As I said it's minor problem. best regards, Przemek _______________________________________________ Harbour mailing list [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
