Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

final folder structure #51

Closed
lehecka opened this issue May 31, 2016 · 2 comments
Closed

final folder structure #51

lehecka opened this issue May 31, 2016 · 2 comments

Comments

@lehecka
Copy link
Contributor

lehecka commented May 31, 2016

We made some changes recently to the folder structure. We pulled reactive-streams-cpp to a separate repo, but kept the subfolder under reactivesocket-cpp. I believe it is just an obsolete artefact.
I want to understand the final folder structure. Here is my proposal:

reactive-streams-cpp (repo)

  • include
  • src
    • utilities
  • test
  • examples
    reactivesocket-cpp (repo)
  • src
    • automata
    • mixins
    • streams
  • test
  • cmake
  • devtools
  • externals
  • ...

The main difference between this proposal and the current state is essentially expanding reactive-streams-cpp/src to the root folder and moving reactivesocket-cpp/reactivesocket-cpp/src one level up.

Please let me know if there were any conversations about this which I missed.

@ghost
Copy link

ghost commented May 31, 2016

We pulled reactive-streams-cpp to a separate repo, but kept the subfolder under reactivesocket-cpp. I believe it is just an obsolete artefact.

I believe the reason folly, wangle, etc. use the same convention, is that you can then simply add a submodule with this library, include CMakeLists.txt and refer to header files with reactivesocket-cpp/ prefix (i.e. the namespacing we thoroughly bikeshedded on in #48). There are probably other ways of achieving this.

Other than that, I believe there are a few levels of indentation missing.

Also, we can't make reactive-streams-cpp depend on reactivesocket-cpp (as a submodule or in any other form), as the latter depends on he former.

@yschimke
Copy link
Member

I believe this is closed, we have a structure I think we are happy with

facebook-github-bot pushed a commit that referenced this issue Jun 3, 2020
Summary:
Typo in python shebang introduced by 0d19e27, probably by accident.

Found while skimming the code.
Pull Request resolved: facebook/openr#51

Reviewed By: steven1327

Differential Revision: D21865922

Pulled By: saifhhasan

fbshipit-source-id: 5f2c2c2fac82078070920915812139f5fef1c7fe
facebook-github-bot pushed a commit that referenced this issue Sep 18, 2020
…deps and use them in tests (#51)

Summary:
Pull Request resolved: facebook/sapling#51

This diff extends capabilities of CargoBuilder in getdeps so that individual manifests can be build even without workspaces. Thanks to that a build for edenapi/tools can be made and its artifacts can be used in mononoke integration tests.

Reviewed By: StanislavGlebik

Differential Revision: D23574887

fbshipit-source-id: 8a974a6b5235d36a44fe082aad55cd380d84dd09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants