структура папок в Visual C ++, когда есть много проектов, зависящих друг от друга

скажем, у меня есть sln, который содержит 10 проектов (с именами от proj1 до proj10), и proj1 является проектом по умолчанию, который генерирует файл EXE.

Моя проблема: как разместить папку «include»?
Я имею в виду, если proj2 использует proj3 (то есть включает в себя заголовочный файл и связывает свой файл lib), как разместить папку «include»?

Есть два подхода:

  1. поместите все заголовочные файлы и файлы lib в другую корневую папку, которая находится на одном уровне проекта

  2. сделайте каждый проект самозакрывающимся, а другие проекты, которые хотят использовать этот проект, должны позаботиться о include-path и link-path. Конечно, мы должны дать правило для макета каждого проекта (например, каждый проект ДОЛЖЕН иметь папку «include» и папку «lib» в корневой папке)

любое предложение?
Спасибо

1

Решение

Когда дело доходит до Visual Studio, мне не нравится ни один из предложенных вами двух подходов, хотя мой наиболее тесно связан с вашим вариантом №2. То, как я люблю организовывать это так:

<SolutionRoot>
<Project1>
project1.vcxproj
someheader.h
somesource.cpp
<Project2>
<Project3>
<Project4>
<Project5>
application.sln

В случае, если это не очевидно, это список квази-каталогов, показывающий некоторые папки проекта и файл базового решения.

Все новые проекты просто добавляются в решение с использованием настроек Visual Studio по умолчанию. Попытка пойти против этого и заставить проекты работать как проекты Linux (lib, include, src так далее) просто в итоге причиняет вам горе, так что не делайте этого.

Теперь я устанавливаю путь «дополнительных включений» в каждом проекте, чтобы $(SolutionDir), Тогда, если я хочу включить что-то из Project1:

#include "Project1/someheader.h"

Преимущество этого заключается в том, что вы не загромождаете свои «дополнительные включения», поэтому легко увидеть, что внешний включает в себя проект имеет.

Что касается ссылок на файлы lib, почему бы не воспользоваться возможностью ссылок на проекты Visual Studio. Честно говоря, ваша жизнь станет проще. Просто подключите его так, чтобы Project2 ссылался на Project1, так далее… Тогда вам не нужно беспокоиться о библиотеках и путях компоновки. Вы делаете это только для наборов инструментов, которые находятся за пределами вашего дерева решений (например распределения, такие как Libpng или же OpenSSL).

Опять же, вы освобождаете этот параметр, чтобы он отображал только связи вне решения. Другое преимущество заключается в том, что ваш порядок сборки определяется неявно, если вы используете ссылки.

1

Другие решения

Я бы пошел с 1-го решения. это делает настройки проекта простыми. Когда мы работали над проектами на C ++, мы всегда собирали файлы заголовков вместе.

0

По вопросам рекламы [email protected]