Включая один исходный файл C в другом?

он в порядке? да, это скомпилирует

, это рекомендуется? нет-.c файлы компилируют в .obj файлы, которые соединены после компиляции (компоновщиком) в исполняемый файл (или библиотека), таким образом, нет никакой потребности включать один.c файл в другого. Что Вы, вероятно, хотите сделать, вместо этого должен сделать.h файл, который перечисляет функции/переменные, доступные в другом.c файле, и включайте.h файл

Нет.

В зависимости от Вашей среды сборки (Вы не определяете), можно найти, что она работает точно способом, которым Вы хотите.

Однако существует много сред (оба IDE и много Make-файлов ручной работы), которые ожидают компилировать *.c - если это произойдет, то Вы, вероятно, закончите с ошибками компоновщика, должными копировать символы.

, Как правило, этой практики нужно избежать.

, Если Вы абсолютно должны #include источник (и обычно его нужно избежать), используйте различный суффикс файла для файла.

Расширение файла не имеет значения для большинства компиляторов C, таким образом, это будет работать.

Однако в зависимости от Вашего make-файла или настроек проекта включенный c файл мог бы генерировать файл отдельного объекта. При соединении, который мог бы вести для удвоения определенных символов.

Язык C не запрещает такой #include, но получающаяся единица перевода все еще должна быть допустимым C.

я не знаю, какую программу Вы используете с .prj файлом. Если Вы используете что-то, любят, "делают" или Visual Studio или что бы то ни было, просто удостоверьтесь, что Вы устанавливаете ее список файлов, которые будут скомпилированы без того, который не может скомпилировать независимо.

Включая файл C в другой файл законно, но не желательная вещь сделать, если Вы не знаете точно, почему Вы делаете это и чего Вы пытаетесь достигнуть.
я почти уверен что, если Вы отправите здесь причину, что позади Вашего вопроса сообщество найдет Вас другим более соответствующим способом достигнуть Вас цель (отмечают "почти", так как возможно, что это - решение, учитывая контекст).

По тому, как я пропустил вторую часть вопроса. Если файл C включен в другой файл, и в то же время, включенное в проект, Вы, вероятно, закончите с дублирующейся проблемой символа, почему соединение объектов, т.е. той же функции будет определено дважды (если они все статичные).

Used properly, this can be a useful technique.

Say you have a complex, performance critical subsystem with a fairly small public interface and a lot of non-reusable implementation code. The code runs to several thousand lines, a hundred or so private functions and quite a bit of private data. If you work with non-trivial embedded systems, you probably deal with this situation frequently enough.

Your solution will probably be layered, modular and decoupled and these aspects can be usefully represented and reinforced by coding different parts of the subsystem in different files.

With C, you can lose a lot by doing this. Almost all toolchains provide decent optimisation for a single compilation unit, but are very pessimistic about anything declared extern.

If you put everything into one C source module, you get -

• Performance & code size improvements - function calls will be inlined in many cases. Even without inlining, the compiler has opportunities to produce more efficient code.

• Link level data & function hiding.

• Avoidance of namespace pollution and its corollary - you can use less unwieldy names.

• Faster compilation & linkage.

But you also get an unholy mess when it comes to editing this file and you lose the implied modularity. This can be overcome by splitting the source into several files and including these to produce a single compilation unit.

You need to impose some conventions to manage this properly though. These will depend on your toolchain to some extent, but some general pointers are -

• Put the public interface in a separate header file - you should be doing this anyway.

• Have one main .c file that includes all the subsidiary .c files. This could also include the code for the public interface.

• Use compiler guards to ensure that private headers and source modules are not included by external compilation units.

• All private data & functions should be declared static.

• Maintain the conceptual distinction between .c and .h files. This leverages existing conventions. The difference is that you will have a lot of static declarations in your headers.

• If your toolchain doesn't impose any reason not to, name the private implementation files as .c and .h. If you use include guards, these will produce no code and introduce no new names (you may end up with some empty segments during linkage). The huge advantage is that other tools (e.g. IDEs) will treat these files appropriately.