Both is possible, so if you find any reason to use one approach instead of the other, go ahead.
I would use the second approach (top level directories are core, module1, module2, etc.) if the different modules are somewhat useful on their own (except maybe the "core" module, if every other module depends on it.)
If all modules depend on each other, and the individual modules are useless without the other modules, use the first approach (top level directories are src, include, etc.)
You have 4 modules for a small offline customer relationship managment (CRM) system:
- "infrastructure" - it contains logging, basic data types, and some functions to abstract away platform dependencies
- "domain" - it contains business logic
- "gui" - it contains the gui, and builds on top of "infrastructure" and "domain"
- "cli" - it contains a command line interface, also builds upon "infrastructure" and "domain".
In this case, I would use the first approach (top level directories are src, include, etc.) The different parts cannot really be used separately, they are all connected. Maybe the "infrastructure" folder compiles without the other folders, but how can you use the resulting.. library?
You have 5 modules for a document management system that reads arbitrary files and converts them to a common format:
- base - contains the basic data types and platform support
- spreadsheets - allows parsing of excel and openoffice spreadsheets
- pdfparser - can read PDF and PS files
- imagescanner - reads JPG, PNG and TIFF files to do OCR with them
- conversiontools - can convert 90 different file formats to more common supported file formats
In this case I would use the second approach (top level directories are core, module1, module2, etc.) - All modules can be used standalone and be useful (except for the "base" module, obviously.) The different modules are somewhat decoupled, and putting them into separate directories clearly communicates to everyone that this is a basic design decision.
When making up examples, it is good to really make up realistic examples. This makes the answer much more obvious. Bad examples are so common, though. A real project has never modules named "module1" and "module2". Without knowing what the modules are, it is not possible to know wether approach 1 or approach 2 is better.