Dunno, my opinion is that kind of flexibiliy just adds up to create confusing setups, so I'm not even sure filters are really a positive thing. I mean, you can create platform filters in code using __PLATFORM__* macros and any code which is compiler dependent is going against good practices, all other situations should be solvable using hbmk2 independent means like hb_mtvm() calls or other predefined macros. Adding up macro support IMO just really helps to create even more confusing scenarios. What is the situation this is needed?
Brgds, Viktor On Tue, May 5, 2009 at 2:28 AM, Pritpal Bedi <[email protected]>wrote: > > Hello Viktor > > > vszakats wrote: > > > > * utils/hbmk2/hbmk2.prg > > + Added translator info to banner. > > > > Thank you. > But still it does not support macro parsing. > > It should be like > > CASE FN_ExtGet( cParamL ) == ".prg" > > cParam := MacroComp( cParam ) > cParam := ArchCompFilter( cParam ) > > IMO it will be more powerful, dynamic feature. > > Regards > Pritpal Bedi > > -- > View this message in context: > http://www.nabble.com/SF.net-SVN%3A-harbour-project%3A-10978--trunk-harbour-tp23371687p23379077.html > Sent from the Harbour - Dev mailing list archive at Nabble.com. > > _______________________________________________ > Harbour mailing list > [email protected] > http://lists.harbour-project.org/mailman/listinfo/harbour >
_______________________________________________ Harbour mailing list [email protected] http://lists.harbour-project.org/mailman/listinfo/harbour
