Hi Przemek, It would be nice to hear some comments on my fixes, I'm not sure what silence means :) But after like 30-40 fixes with no positive (or any) feedback it's really difficult to know where we stand. I hope we're advancing.
> I do not know the details of hbmk2 and what how you want to > implement it internally. I do not want to force any internal > solution for you. Just simply I do not have enough time and > possibilities to make tests with different windows compilers > and it's the reason I haven't committed my .prg replacement > to hb* scripts to SVN. After 3-4 weeks of 24/7 dedication I'm running out of free time myself, too. I'd like to close existing features. > hb* scripts works only with GCC based compilers so it was quite > easy job to have hbcc working. I understand to things are much > more complicated when other compilers are also supported and you > may need to make it in different way. How is your choice. Yes, exactly. That's why I told in the beginning that hbmk2 can never be a 100% copy of hbmk, the scope is wider, problems are different. We should cover what's important, and let those which are really problematic or against the concept. One of these is passing down C options through hbmk command line to the C compiler f.e.. > When the basic hb* script functionality will be replicated then > the next step is support for cross compilation. > Now hbmk2 for compilers shows: > linux : gcc, gpp, owatcom, icc, mingw, mingwce > mingw and mingwce are not Linux. It's only one of posisble cross > compilation. Create Windows or WindowsCE binaries in Linux if > MinGW* environment is installed. There are different ports of > MinGW*, f.e. for BSD or Darwin so it should not be bound with > Linux directly though if for some reasons its easier for your > then we can keep it in such way but it should be added also to > other *nix based builds. > I think that it will be better to implement some more general > solution which will have: > 1. support for C compiler prefix > 2. PATH expansion (HB_SETENV()) > 3. default harbour compiler switches like: > -D__PLATFORM__WINCE > -D__PLATFORM__WINDOWS > -undef:__PLATFORM__UNIX > -undef:__PLATFORM__LINUX > > It will be nice if all such settings for different cross compilations > can be grouped in single hbmk.cfg file, f.e. sth like: > > [mingw] > ARCH=win > CCPREFIX=i386-mingw32- > PATH=/opt/xmingw/bin > HB_OPT=-undef:__PLATFORM__UNIX -undef:__PLATFORM__LINUX > HB_OPT+=-D__PLATFORM__WINDOWS > LIBDIR=/usr/lib/harbour-win > HARBOUR=/usr/bin/harbour > > [mingwce] > ARCH=win > CCPREFIX=arm-wince-mingw32ce- > PATH=/opt/mingw32ce/bin > HB_OPT=-undef:__PLATFORM__UNIX -undef:__PLATFORM__LINUX > HB_OPT+=-D__PLATFORM__WINCE -D__PLATFORM__WINDOWS > LIBDIR=/usr/lib/harbour-wce > HARBOUR=/usr/bin/harbour I'd try getting closer (or be similar) to the config requirements of the builds (which also needs some cleaning BTW). CCPATH and CCPREFIX are already supported by hbmk2, LIBDIR is HB_LIB_INSTALL, HARBOUR ~is HB_BIN_INSTALL. The rest can be passed as .hbp configuration (PRGFLAGS=). I don't want to develop an .ini engine, and the one in core is very weak, so maybe using simple .hbp files for this purpose could help (or some other flat format), with some new values are added. I have to think about it, but only after closing all current features. I'm waaay over all my time/energy budget right now. The next thing which should also be addressed is support for .clp files > in Harbour compiler. Now it partially works as hbmk2 scripts but here > one thing should be changed. hbmk2 should always add en extension if > not given to @script. Otherwise on platforms which does not use .exe > extension it begins to read final binary application as scripts if it > has the same name. I hope it's a minor problem and can be easy fixed. I've committed a patch to add extension .hbm to extension-less @ filenames. The bigger problem is support for .clp files in compiler which is not > Clipper compatible and should be fixed but this needs serious modifications > in generated .c and .hrb files. I hope it will be fixed later so now > we can leave it as is. As for .clp, I don't know, never used them, couldn't find docs about the format or details about it. So we can do two things: Either drop it for hbmk and offer .hbm as a superior replacement, or (if we get to know the format details), we may write a parser for .clp files. Here the problem we have is that hbmk2 doesn't know if a @ option refers to an .hbm or a .clp if no extension is passed. Finally, maybe .clp is already parsable by .hbm parser... For the basic case it seems to be, but I don't know the .clp format enough to tell precisely. Since you say "serious modifications in compiler", maybe it's more than just parsing. Again, never used .clps (or at least I cannot remember when ;). So, I'm not sure that precise .clp support is very important for hbmk, maybe not even for Harbour. Brgds, Viktor
_______________________________________________ Harbour mailing list [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
