On Wed, Jan 6, 2016 at 1:50 PM, Louis Dionne
Rene Rivera
writes: On Tue, Jan 5, 2016 at 4:52 PM, Louis Dionne
wrote: [...]
If there are other uses, could you please elaborate? This is not rhetorical; such uses would point out other places that need to be changed to accommodate my proposal.
I don't know all of them ATM. Daniel maintains some extra tools that deal with that file. So he will need to tell us.
Ok no problem. Let's hope Daniel sees this thread.
We'll probably need to start another thread so he notices. I guess this is personal preference, then. Outside of an IDE, I find it very
useful to have commands like `ls` exclude dotfiles and dotdirs by default. But again, you could argue for the contrary, so let's assume this is not a strong argument for or against.
Indeed.. As I add aliases to ls that show the dot files :-) Since it's become popular to hide dot files ;-)
[...]
2. Suggest using a .boost _directory_ instead of a single file
Renaming the directory seems like a better choice to me.
In retrospect, it probably is a better choice indeed. The changes required to existing tools would also be even more trivial, and we could easily do a batch renaming for all modules.
OK, thinking about it more, now that my brain has time.. I think the best I can think of is to have the dir be ".boostlib". It directly communicates the intended use "Stuff about the Boost library". Yes, exactly. When reasonable, I want to minimize the cohesion between Hana
and Boost. In its current state, Hana is a completely standalone library, which also happens to work inside the Boost tree. I'd like it to stay that way, since I find it gives me more freedom to use Hana the way I want.
Interesting that Predef is also that way :-)
[...]
Right. You will definitely need help. At least to go in and merge all the PRs involved in this. Since only admins (aka the release team) has enough privileges to do this unilaterally. And it needs to be unilaterally,
since
the last time we did such a change (creating that meta dir) it was impossible to get authors to help.
If I provided a script to do it, could someone from the release team update all the repositories?
Sure.
Such a script should be fairly simple to write, but in comparison creating 100+ PRs and merging them would be quite cumbersome.
Note, I would prefer if the script did *everything* needed to do the rename. Which means starting from nothing, doing the clones, branch switches, renames, commits, and pushes.
One problem I see is for those libraries maintained as forks; in this case the original repository would need to be updated, which would require authors to cooperate. But I think all libraries maintained as forks have authors that are around, so it should be doable.
Wouldn't they get merge conflicts and be forced to resolve them? -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail