directory structure for a project that mixes C++ and Python
Question: Say you want want to create a programming project that mixes _C++_ and
_Python_. The **Foo** _C++_ project structure uses _CMake_ , and a _Python_
module is created by using _Swig_. The tree structure would look something
like this:

    
    
    ├── CMakeLists.txt
    ├── FooConfig.cmake.in
    ├── FooConfigVersion.cmake.in
    ├── Makefile
    ├── README
    ├── foo
    │   ├── CMakeLists.txt
    │   ├── config.hpp.in
    │   ├── foo.cpp
    │   └── foo.hpp
    └── swig
        └── foo.i
    

Now you would like to make use of the **Foo** project within a _Python_
project, say **Bar** :

    
    
    ├── AUTHORS.rst
    ├── CONTRIBUTING.rst
    ├── HISTORY.rst
    ├── LICENSE
    ├── MANIFEST.in
    ├── Makefile
    ├── README.rst
    ├── docs
    │   ├── Makefile
    │   ├── authors.rst
    │   ├── conf.py
    │   ├── contributing.rst
    │   ├── history.rst
    │   ├── index.rst
    │   ├── installation.rst
    │   ├── make.bat
    │   ├── readme.rst
    │   └── usage.rst
    ├── bar
    │   ├── __init__.py
    │   └── bar.py
    ├── requirements.txt
    ├── setup.cfg
    ├── setup.py
    ├── tests
    │   ├── __init__.py
    │   └── test_bar.py
    └── tox.ini
    

This structure was crated by using [cookiecutter's pypackage
template](https://pypi.python.org/pypi/cookiecutter/0.7.2). A BoilerplatePP
template is also available to generate a _CMake_ _C++_ project using
cookiecutter (no _Swig_ part). So now that I have the structure of both
projects, and considering that the development will take place mainly in
_Python_ and the the project will be run in different systems, I need to
address the following questions:

  1. What's the best way to mix them? Should I collapse both root directories? Should I have the **Foo** _C++_ project as a directory of the **Bar** project or the other way around? I may be inclined to put the entire _C++_ structure shown above in a folder at the root level of the _Python_ project, but I would like to know _a priori_ any pitfalls as the _CMake_ system is quite powerful and it may be convenient to do it the other way around.
  2. In case I decide to put the **Foo** project as a directory within **Bar** , is the _Python_ setuptools package as powerful as the _CMake_ build system? I ask this because when I take a look at the **Bar** project, at the top level it seems there's only a bunch of scripts, but I don't know if this is the equivalent to _CMake_ as I'm new to _Python_.
  3. The **Bar** project outlined above has a single _bar_ directory, but I assume that whenever this project expands, instead of having many other directories at the root level, other directories containing _Python_ code will be placed within _bar_. Is this correct (in the _Pythonic_ sense)?
  4. I assume that a single egg will be produced from the entire project, so that it can be installed and run in many different python systems. Is the integration of the module created by the **Foo** project easy? I assume that this module will be created in a different directory than _bar_.
  5. In order for the _Python_ code within the _bar_ directory, the module created by _Swig_ has to be available, so I guess the most straightforward way to do this is to modify the environmental variable `PYTHONPATH` using the _CMake_ system. Is this fine or is there a better way?


Answer: **If the C++ application has no use outside the Python package that will
contain it:**

You can pretty safely place the C++ code within the python package that owns
it. Have the "foo" directory within the "bar" directory within your example.
This will make packaging the final Python module a bit easier.

**If the C++ application is reusable:**

I would definitely try to think of things in terms of "packages", where
independent parts are self-contained. All independent parts live on the same
level. If one part depends on another, you import from its corresponding
"package" from the same level. This is how dependencies typically work.

I would NOT include one within the other, because one does not strictly belong
to the other. What if you started a third project that needed "foo", but did
not need "bar"?

I would place both "foo" and "bar" packages into the same "project" directory
(and I would probably give each package it's own code repository so each
package can be easily maintained and installed).

