> Viktor Szakáts wrote: >> >> I'm not sure what you mean, maybe ".hbp parser"? hbmk2 doesn't >> have an .hbp parser _API_ ATM, but it of course does have >> a parser internally. With some internal rearrangement, it's >> pbly possible to create an API call to parse an .hbp file, >> and return a structure with the full content. >> >> [ with some limitations, f.e. in such context it's quite >> difficult to retain external references to .hbm/.hbp files >> on a save operation, but that's probably not a big problem >> overall. ] >> > > I am lost a little. > > hbmk2 exploits > .hbc > .hbm > > I was considering retaining HBIDE settings and all allied stuff > in .hbp extention. But by above I gathered that .hbp extention > is already being exploited by hbmk2.
Yes, .hbp has the same format as .hbm, but it's used to denote a project. If you pass multiple .hbp files to hbmk2, it will build each of them in separate passes. > If it is not hard, can you provide some basic structure info about > .hbc, .hbm and .hbp ( if it is in use ) ? It is, but if you stick to the format, you can still use it. In this case it'd be better to expose the parsing logic from hbmk2 code through an API though. .hbp is the same as .hbm as far as the format goes, It's a file which contains command line options with the exact same syntax you would use on cmdline, you can have more than one options in one line and you can have any number of lines. Comment line begin with # as a convention. I suggest to create one option each line to keep it clean. > I plan to recreate all the files necessary to launch hbmk2 from an HBIDE > project definition. That's good. Brgds, Viktor _______________________________________________ Harbour mailing list (attachment size limit: 40KB) Harbour@harbour-project.org http://lists.harbour-project.org/mailman/listinfo/harbour
