spirit classic modularization
While I was in Aspen I split Spirit and Spirit Classic into separate Git repositories: https://github.com/boost-lib/spirit https://github.com/boost-lib/spirit_classic The manifest entries begin here, and as you can see, are quite long for these two libraries: https://github.com/ryppl/boost-modularize/blob/master/manifest.txt#L643 This is mostly due to the limited expressivity of the manifest language, but regardless... The question, for Spirit developers: which arrangement is better? Should both spirits go back into a single repository? -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Dave Abrahams wrote:
While I was in Aspen I split Spirit and Spirit Classic into separate Git repositories:
https://github.com/boost-lib/spirit https://github.com/boost-lib/spirit_classic
I prefer the above even though it would require that I make changes to serialization library to explicitly select spirit_classic. Right now the selection occurs under the covers in a way which is not obvious to me. It does work which is good. But still it hides what's going on which usually comes back to haunt me. Robert Ramey
The manifest entries begin here, and as you can see, are quite long for these two libraries:
https://github.com/ryppl/boost-modularize/blob/master/manifest.txt#L643
This is mostly due to the limited expressivity of the manifest language, but regardless...
The question, for Spirit developers: which arrangement is better? Should both spirits go back into a single repository?
On 5/22/2012 5:20 AM, Robert Ramey wrote:
Dave Abrahams wrote:
While I was in Aspen I split Spirit and Spirit Classic into separate Git repositories:
https://github.com/boost-lib/spirit https://github.com/boost-lib/spirit_classic
I prefer the above even though it would require that I make changes to serialization library to explicitly select spirit_classic. Right now the selection occurs under the covers in a way which is not obvious to me. It does work which is good. But still it hides what's going on which usually comes back to haunt me.
If it will haunt you, it would've haunted you now, and it would have haunted many others, for that matter, after many years that it has been in place. It is obvious, if you spare a moment to understand. In short: forwarding headers. Regards, -- Joel de Guzman http://www.boostpro.com http://boost-spirit.com
On 5/22/2012 12:40 AM, Dave Abrahams wrote:
While I was in Aspen I split Spirit and Spirit Classic into separate Git repositories:
https://github.com/boost-lib/spirit https://github.com/boost-lib/spirit_classic
The manifest entries begin here, and as you can see, are quite long for these two libraries:
https://github.com/ryppl/boost-modularize/blob/master/manifest.txt#L643
This is mostly due to the limited expressivity of the manifest language, but regardless...
The question, for Spirit developers: which arrangement is better? Should both spirits go back into a single repository?
At this point, I think I would prefer the new arrangement. I'd like that especially if there's a way for the build system (CMake?) to copy/forward the original headers back into it's former place for backward compatibility. I'd also take this opportunity to clean up some include cruft there. I can do that once we get write access. (BTW: will authors have the privilege to issue and revoke write access to its contributors limited to its module boundaries?) Regards, -- Joel de Guzman http://www.boostpro.com http://boost-spirit.com
on Mon May 21 2012, Joel de Guzman <joel-AT-boost-consulting.com> wrote:
On 5/22/2012 12:40 AM, Dave Abrahams wrote:
While I was in Aspen I split Spirit and Spirit Classic into separate Git repositories:
https://github.com/boost-lib/spirit_classic
The manifest entries begin here, and as you can see, are quite long for these two libraries:
https://github.com/ryppl/boost-modularize/blob/master/manifest.txt#L643
This is mostly due to the limited expressivity of the manifest language, but regardless...
The question, for Spirit developers: which arrangement is better? Should both spirits go back into a single repository?
At this point, I think I would prefer the new arrangement. I'd like that especially if there's a way for the build system (CMake?) to copy/forward the original headers back into it's former place for backward compatibility.
There's a way, but I don't think I want to take responsibility for doing that job. If you want that, I'm afraid you'll have to do it yourself.
I'd also take this opportunity to clean up some include cruft there. I can do that once we get write access.
(BTW: will authors have the privilege to issue and revoke write access to its contributors limited to its module boundaries?)
Authors will be able to grant and revoke write privileges on each of the repositories for which they are responsible. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
participants (3)
-
Dave Abrahams -
Joel de Guzman -
Robert Ramey