I'm part of a studio that's looking to replace our internal build config/management system with premake. I'm an incredible premake nub, so please forgive any dumbness on my part.
So far, premake seems awesome except for one item - sharing projects between solutions. In our codebase, we have many projects that are libraries shared across solutions (for example one solution for the game and another for a tool that links in game libs). We're happy to manage everything w/ premake, but reading the docs, I'm not clear what the recommended best practice is for this.
In particular, it's very common for one of our users to add a file, regenerate a project, and then be done with it. Solutions are only regenerated when a project is added or removed. However, in premake it seems that solutions and projects are more tightly coupled. Is there a good/recommended way to decouple them? Or should we simply repeat the project information across all solutions (using includes or somesuch to eliminiate duplication) and just rebuild one of them when a new file is added to a project?
Thanks in advance for any insight/hints.
PS - I saw http://industriousone.com/topic/add-already-existing-project-solution, which made me worry that what I want to do isn't supported, but we don't have quite the same use-case as described by that poster.

Update: I found http://industriousone.com/post/share-projects-between-solution after realizing there was a separate Help forum. Is this still the recommended best practice?
>I found http://industriousone.com/post/share-projects-between-solution after realizing there was a separate Help forum. Is this still the recommended best practice?
This trick is probably harmless - however, it has nothing to do with prevention of solution file rewriting when project changes.
>In our codebase, we have many projects that are libraries shared across solutions (for example one solution for the game and another for a tool that links in game libs).
In future recommended way to do this will be usages, however this feature is still unreleased.
Yes, that link shows the right way to do it.
Usages are intended to solve a different problem. A bridge to cross when we get to it.
>Usages are intended to solve a different problem.
Why cannot them solve this problem too? Let's assume we have solution S1 which builds library A, and we want to use A in solution S2 as external dependency (i.e. A is not build as a part of S2). It could be implemented through export of A usage from S1.