[akesm]

Hello

I have got a code, in its main makefile it is like

faceProperties/faceProperties.C
faceProperties/faceComp/faceComp.C

Solver.C
EXE = $(FOAM_USER_APPBIN)/Solver.C

Worth mentioning that in main folder where the main Make folder exists I have another folder named as faceProperties containing files faceProperties.C and faceProperties.H which besides in itself contains another folder named as faceComp which this also contains faceComp.C and faceComp.H. In faceProperties folder there is another Make folder containing makefile as

interfaceProperties.C
faceComp/aceComp.C
LIB = $(FOAM_LIBBIN)/libfaceProperties

Is it like that when you run the main Make file it automatically runs the other makefile and recognizes the sub .C files needed for running the main solver?
What was wrong by just putting the sub .C and .H files in the main mother folder and not introducing these sub Make folders and sub .C and .H files?
Do I need to run the sub Make files also? or running the main Make file is enough?

what does the third line below mean? why is does not have _USER and also it is named as libfaceProperties? what does "lib" in libfaceProperties refer to?

faceProperties.C
faceComp/faceComp.C
LIB = $(FOAM_LIBBIN)/libfaceProperties

[floquation]

First things first:
That is not a Makefile.
It is the Make/files file from the wmake system, which is derived from make... But it's not actually a Makefile.

Is it like that when you run the main Make file it automatically runs the other makefile and recognizes the sub .C files needed for running the main solver?

No, it will not (as far as I know). That's why the main OF src tree ($FOAM_SRC) supplies a Allwmake script. If you'd open it, you'd see that it calls wmake on each subdirectory. Similarly, "$FOAM_SRC/transportModels" has an Allwmake script for its subdirectories.

What was wrong by just putting the sub .C and .H files in the main mother folder and not introducing these sub Make folders and sub .C and .H files?

Nothing "wrong" with that... But it's bad practice in general.
If OpenFOAM would do that, it would have (idk?) 500 .C files and 500 .H files in the same directory. You can probably see that this would be absolutely terrible.
The same principle applies to your solver, although you could argue that two files more or less does not matter.

Do I need to run the sub Make files also? or running the main Make file is enough?

Depends...
In your case, the .C files of the subdirectory were already added to your main Make/files. Therefore, they will already be compiled, and included into the mentioned EXE:

EXE = $(FOAM_USER_APPBIN)/Solver.C

However, that is a really bad name for an executable... Why call it ".C"? Better would be:

EXE = $(FOAM_USER_APPBIN)/Solver

As executables do not have an extension (on Linux).

Now, if we you were to leave these subdirectory .C files out, then they wouldn't be compiled, nor added to the Solver executable. Therefore, the Solver executable will have a smaller size... But code would be missing, so your solver cannot execute. Your Solver will then search for a dynamic library that contains the code in $FOAM_USER_LIBBIN or $FOAM_LIBBIN.
However, it will only do so if that library was included in Make/options. (If it is not, I think that the code will not compile in the first place.)

Your subdirectory's Make/files make such a library. Read on:

what does the third line below mean? why is does not have _USER and also it is named as libfaceProperties? what does "lib" in libfaceProperties refer to?

It should have _USER. You don't want to write a user library to the main OF tree.
It is a (dynamic) library. All dynamic libraries start their names with "lib": that is mandatory. For instance, the library fooBar will be written to the file "libfooBar.so." Any executable that requires fooBar will look for "libfooBar.so" in all directories present in your LD_LIBRARY_PATH environmental variable.

A dynamic library permits you to compile this code independent of your solver. Also, you'll be able to use that library's code for multiple solvers. It also becomes easier to inject new custom code, as you don't have to re-compile everything: it is dynamically linked at runtime.
Imagine if OpenFOAM was monolithic instead... Then any kind of change would have required to recompile virtually everything! That would take hours for the smallest change... That's a lot less maintainable.



In other words:
Your main directory's Make/files does already compile all code. Calling wmake on the subdirectory would create a dynamic library of that code, but it wouldn't be used for your solver, as your solver executable already includes that code within itself.
Usually, you'd want to dynamically link such code... If it is code that can be used by multiple executables(/solvers). That is done by the subdirectory's Make/files with its "LIB=" line.
If this code is very specific to your solver, you might as well include the code directory into the executable, which your main Make/files currently does.