Bjørn Roald wrote:
Fair enough, but it sort of escape me why you are so determined to get the headers into a conventional "include" directory, on the grounds that that is what users expect, while you seem perfectly fine with keeping the libraries hidden inside a very unconventional "stage" directory. What other project or software distribution use a "stage" directory? I can not think of one.
There are two reasons; the first one is that lib and libs are too close and will create a lot of confusion; the second one is that I'm not very proficient with Boost.Build, so I kept my changes to a minimum.
But as I said, I wanted bpm to work on the current structure.
Why? It is not like that structure exist before bpm download files. So there is no current structure to work on. Am I missing something?
bpm itself wouldn't care, but if I moved libs/ to modules/ or components/ and stage/lib/ to lib/, I would have needed to patch all references to libs in Boost.Build (and potentially anywhere else), and I haven't investigated whether this is feasible. Perhaps it is, I just didn't check. (I would have then needed to maintain these fixes, as well.) The package script would also need to be fixed, since it currently takes its input from the source tree, but that's easier. In short, I could live with stage/lib, so I didn't feel that strongly about fixing it. I did feel strongly about -I <root>, so I fixed _that_. :-)