On Wed, 2018-06-20 at 15:09 +0200, Michael Van Canneyt wrote: > > On Wed, 20 Jun 2018, Mark Morgan Lloyd wrote: > > > The other alternative would be break the compiler in such a way that it > > was usable from a standard makefile, but since there isn't separate > > compilation of definition and implementation parts this would probably > > impact on type safety. I believe that this too has been debated in the > > past, and has attracted even less enthusiasm than a hook for an extrnal > > preprocessor preprocessor. > > Nothing stops people from preprocessing their code if they need really > advanced preprocessing: The toolchain can handle it already. > > But there is no need to integrate it in the compiler and thus needlessly > complicating it even more. The consequences of such a step are far-reaching. > > And till now, no-one has presented the really pressing use cases that would > warrant such a step.
The only use case for me would be macros having more than one parameter, needed when translating C-code. But I speak up for another reason: Long ago, at the time of fpc 1.9.x or 2.0.x I did some digging in compiler source code, the lexer and parser part. IIRC there were some hooks for calling a proprocessor in the code at that time. If they are still there, wouldn't it be a solution for both sides? The compiler programmers only have to activate (or complete) a way to call a preprocessor, solving the problem of mangled error messages. The preprocessor user could implement whatever is needed on his or her side? My 2 cent, Marc -- Marc Santhoff <m.santh...@web.de> _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal