On 10/03/2012 05:16 PM, David Engster wrote:
> I'm currently trying to fix CEDET compilation for two cases (namely
> cedet-build.el and Emacs 23.1) and noticed several problems. I fixed
> most of those, but one has to do with SRecode which I'll never really
> understand... ;-)
> The problem is the generation of the parser srt-wy.el from srt.wy. This
> currently fails because there's a setter function for
> `srecode-map-load-path', which calls `srecode-map-update-map'. These
> setter functions are called as soon as the file is loaded, leading to a
> cascade that in the end needs srt-wy.el, which does not exist yet. I've
> commented out that setter function for now, but I guess it is needed for
> something since now the tests fail...
> We already have the same chicken/egg problem with grammar.wy, which is
> why we have gram-wy-fallback.el. We could do the same for srt-wy, but
> I'm still hoping there's another solution.
> If you wonder why that worked for a long time: I am now loading
> cedet-devel-load.el before generating a parser, since I noticed that
> otherwise we are pulling in things from CEDET that ship with Emacs
> proper, which we want to avoid.
cedet-devel-load.el sets up the SRecode system, which will in turn force
srecode/map to load. I don't think srecode is required to build
anything directly in CEDET.
Perhaps cedet-devel-load should have some input option that only sets up
the absolute minimum needed to build. For example, just in front of the
line about canned-configs it could branch, and skip the rest iff in
batch/build mode, however it is best to detect that. That should solve