Viktor Szakáts wrote:
>
> This function requires native path separators,
> so to fix this, always convert to native before
> passing them to it.
>
Okay.
> You can even save back native pathseps to
> file, but you should make sure to convert
> them to native when you load them. This
> way the disk files are platform independent.
>
Yep, this is exactly what I want to achieve.
> You can store it with consistent slash type,
> but since these files can be edited by humans,
> and also hbmk2 is insensitive of the slash format,
> always be prepared to any format when reading
> the files.
>
Yep I am aware.
>> RootPath will always be the absolute path ( os specific ) of .hbp file.
>
> This is where we started from, just lookup the original
> function. It's called 'PathProc()'.
>
Oops, forgot about that.
>> 3) Is is normal if info in .hbp is sectionized ? I mean, switches and
>> sources separation,
>> as with you sent the function to parse .hbp. hbIDE needs information in
>> sectioned way,
>> free format cannot be manipulated. Once existing .hbp will be submitted
>> to hbIDE,
>> it will parse its contents, sectionize, and will overwrite the existing
>> .hbp with
>> added .hbi specific info constructed prefixed with #.
>
> I'd suggest to touch it only as absolutely necessary.
>
> As for "sectionizing", I think it's not very good,
> since you need to be able to parse native .hbp files
> anyway, so section can get deleted, or not present at
> all. For pure cosmetic reason you could add them, but
> IMO it's not very polite to add unnecessary information
> to config files.
>
By 'Sections' I mean ( .hbp parlance ) "Switches" and "Sources"
I am more concerned about "Souces" which user will be "adding/deleting"
the visual way. For that matter I do not want user to open .hbp
in a text editor, rearrange the information and then turn to hbIDE.
How this can be achieved?
> For a start you can simply write an .hbp file based
> on in-memory information using your own formatting.
>
> F.e. options first, empty line, source files, empty
> line, hbide options.
>
> Later this can be extended to keep track of change
> in-memory and try to replicate original format, with
> original comments, when writing out the file.
>
Here it becomes difficult. If .hbp is tuned to receive
first swiches then sources, no issues. But if it is a mix
switch(es) | source(es) | switch...
then probably this cannot be achieved in reasonable way.
Also .hbp parser provides switches first then sources.
hbIDE provides two sections to keep information:
1) Compile/Link flags and 2) Sources.
> To make a little simpler, I'll add a new switch to
> hbmk2, which it will always ignore, so it can used
> to specify hbide (or other 3rd party tool switches),
> I plan to call it -3rd=<string>, so you can add
> hbide specific options, without fiddling with
> comment trick, like this:
> -3rd=-hbide-specialoption
> -3rd=-hbide-projectfriendlyname=Hello
>
This feature will be nice but this will only needed for
couple of places which can be acieved with # at the end or start.
In a nutshell, hbIDE needs sources to be located/deleted/added.
Rest of the part of .hbp can remain intect.
Please keep in mind that we are building a .hbp in visually
interactive way. Let us push already existing .hbp's at back line
at this moment.
-----
enjoy hbIDEing...
Pritpal Bedi
_a_student_of_software_analysis_&_design_
--
View this message in context:
http://n2.nabble.com/SF-net-SVN-harbour-project-13763-trunk-harbour-tp4513022p4551258.html
Sent from the harbour-devel mailing list archive at Nabble.com.
_______________________________________________
Harbour mailing list (attachment size limit: 40KB)
[email protected]
http://lists.harbour-project.org/mailman/listinfo/harbour
