Hi Antony, > Le 3 juil. 2022 à 23:15, Anthony Heading <a...@ajrh.net> a écrit : > > Another patch I've had lying around for a while... It's easy to use a > custom skeleton, just by using the '-S <skeleton>' flag. But it's harder to > customize their sub-includes because they have fixed paths, for example in > lalr1.cc: > > m4_include(b4_skeletonsdir/[c++.m4]) > > Attached patch sets the directory of any custom skeleton, and then the > b4_skeletonsdir, as '-I' search-path flags to m4, and makes the c++.m4 > include path unqualified. > > If it makes sense for adoption, I can change all the various other system > skeleton files similarly and submit a larger patch as github PR, but > hopefully attached (which is all I personally use) is enough to explain the > idea.
Could you elaborate a bit your use case? Are you using a regular lalr1.cc but a tuned c++.m4? I'm not sure I want to support that: Bison's lalr1.cc wants its own c++.m4, etc. However I can understand that when you add -Smyskeletons/lalr1.cc, then you want lalr1.cc to be free to depend on other files in myskeletons/. However, instead of hard-coding this automatic -I on the base name of -S, I would rather truly introduce -I and let the user decide what to use. With your -S, myskeletons/lalr1.cc would have to include `c++.m4`. I think it should include `myskeletons/lalr1.cc`. That's why I would prefer -I: the user decides what the root is.