> > 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. 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. > 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. Brgds, Viktor
_______________________________________________ Harbour mailing list [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
