You actually can just cmake and that is all you need!

  [in any folder out of source]
  mkdir build
  cd build
  cmake [source folder]
  make
  source devel/setup.bash
  roslaunch your_fancy_package demonstrator_nodelet_or_whatever.launch

That works, but you can't mix it with catkin_make or other build tools (rosbuild). I.e. you can't just invoke catkin_make there, this won't work afaik.

The source folder must contain a main CMakeLists.txt symlink which points to `/opt/ros/[distribution e.g. kinetic]/share/catkin/cmake/toplevel.cmake`. This symlink will be created when calling "catkin_init_workspace". You can also just put a copy of that file there to commit it in git. I do this and even modify it to include my own cmake modules and debugging stuff.

You can now layout your folders any way you want. That means the packages don't need to all be in the same folder, but can be grouped as necessary.

Example project layout:

  project
  ├── cmake
  |   └── FindSomePackage.cmake
  ├── doc
  |   └── index.md
  ├── project_msgs
  |   ├── msg
  |   |   ├── Foo.msg
  |   |   └── Bar.msg
  |   ├── CMakeLists.txt
  |   └── package.xml
  ├── project_utils
  |   ├── include
  |   |   └── project_utils
  |   |       └── foo.h
  |   ├── launch
  |   |   └── ...
  |   ├── scripts
  |   |   └── do_stuff.py
  |   ├── src
  |   |   └── foo.cpp
  |   ├── CMakeLists.txt
  |   └── package.xml
  ├── components
  |   ├── heisenberg_compensator
  |   |   ├── include
  |   |   |   └── ...
  |   |   ├── src
  |   |   |   └── ...
  |   |   ├── CMakeLists.txt
  |   |   └── package.xml
  |   ├── warp_controller
  |   |   ├── include
  |   |   |   └── ...
  |   |   ├── src
  |   |   |   └── ...
  |   |   ├── CMakeLists.txt
  |   |   └── package.xml
  |   ├── ...
  |
  ├── .gitignore
  ├── readme.md
  └── CMakeLists.txt -> /opt/ros/[distribution e.g. kinetic]/share/catkin/cmake/toplevel.cmake
        should contain set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} ${CMAKE_CURRENT_SOURCE_DIR}/cmake)

You can put software components/packages in folders that are structured similar to project_utils / project_msg on any sublevel, I don't know what happens when you directly nest them though.. I wouldn't do that.