Update for project files

[elfring]

The JkDefrag software package contains project files for a well-known development environment like Microsoft Visual C++. They need a couple of updates for the generation of the other required files.

There is also a Makefile available. It works with an interesting detail. The file "JkDefragLib.obj" is referenced by several executables. It should be generated with appropriate settings into separate output directories for each purpose like static module or dynamic link library, shouldn't it?
I guess that there are still a few open issues to guarantee consistency in the build process. Is anybody interested to introduce the CMake system to avoid to rewrite the "tricky" Makefile manually?

[jeroen]

They need a couple of updates for the generation of the other required files.

The example Visual C project compiles with zero errors and zero warnings.

It should be generated with appropriate settings into separate output directories

No, it shouldn't. There are no output directories, and the settings you are referring to are linker settings, not compiler settings.

I guess that there are still a few open issues to guarantee consistency in the build process.

I respectfully disagree. I happen to know that you have been making changes to the sources, and any errors that you are getting now are your own doing.... And I think a tool such as CMake is not indicated, and would make things a lot more complicated.

[elfring]

The example Visual C project compiles with zero errors and zero warnings.

The include and library paths must be adjusted for each installation.
I needed to add an additional dependency for the file "advapi32.lib".

There are no output directories, and the settings you are referring to are linker settings, not compiler settings.

Visual C++ distinguishes between debug and release builds already. (The Makefile can only switch a few options by (un)commenting the macros "COMPILE" and "LINK" so far.)
There is another selection between the static embedding of object code and the importing for calls to the shared library (DLL).

[elfring]

I have refactored the Makefile for my source code branch. Are any software developers and programmers interested to look at effects by the available configuration options?

[jeroen]

Thank you very much for sharing your ideas, but the current Makefile functions perfectly well for me. If you make a customized version of JkDefrag from the sources, then I expect you may have to make some changes to the Makefile. Please feel free to do so.

[elfring]

We can be lucky that it seems to work. I would like to point out a few details for further considerations.

• There are different compiler options like /MT for a static executable file and /LD for a dynamic link library. I guess that it is an open issue to use the file "ScanNtfs.cpp" for both purposes without adjusted parameters.
  
• There is a distinction needed for DLL functions that can be imported from the library if the header "JkDefragLib.h" should ever be included by other sources instead of embedding the complete object code.
• How do think about the support for program databases?

[jeroen]

We can be lucky that it seems to work.

I disagree. The Makefile is perfectly allright. The fact that you would like to see some changes does not mean it's a bad Makefile. If changes are necessary then I am perfectly willing to make them, but at the moment I see no need to make changes.

• There are different compiler options like /MT for a static executable file and /LD for a dynamic link library. I guess that it is an open issue to use the file "ScanNtfs.cpp" for both purposes without adjusted parameters.

These are linker options. Not compiler options. The compiler options for compiling ScanNtfs.cpp into an .obj file are the same, whatever the .obj file is linked into.

• There is a distinction needed for DLL functions that can be imported from the library if the header "JkDefragLib.h" should ever be included by other sources instead of embedding the complete object code.

No distinction is needed. C programmers will not use the DLL, but embed the sources into their project, because it's easier and removes the need for distributing a DLL with the program. The DLL is only used by programmers using other languages, such as Delphi. And they cannot use the .h file.

• How do think about the support for program databases?

The example "debug" lines in the Makefile already do that.

[elfring]

How do you think about the following example?

Code:

!IFNDEF PROJECT_NAME
PROJECT_NAME=JkDefrag
!ENDIF

!IFNDEF MAKEFILE
MAKEFILE=Makefile
!ENDIF

!IF 1
BUILD_TYPE=release
PROJECT_EXE_PDB=
PROJECT_CMD_PDB=
PROJECT_SAVER1_PDB=
PROJECT_SAVER2_PDB=
PROJECT_LIB_PDB=
CFLAG_PDB=
LFLAG_PDB=
CFLAG_RUNTIME_STATIC=/MT
CFLAG_RUNTIME_DLL=/MD
CFLAGS_COMMON=/Gd /c /W3 /nologo /DNDEBUG /O2 /Fo"$@"
LFLAGS=/nologo /INCREMENTAL:NO /OPT:REF /OPT:ICF /OUT:"$@"
CFLAGS_DLL=/LD /D_EXPORTING
!ELSE
BUILD_TYPE=debug
PROJECT_EXE_PDB="$(OUT_DIR_BIN)\$(PROJECT_NAME).pdb"
PROJECT_CMD_PDB="$(OUT_DIR_BIN)\$(PROJECT_NAME)Cmd.pdb"
PROJECT_SAVER1_PDB="$(OUT_DIR_BIN)\$(PROJECT_NAME)ScreenSaver1.pdb"
PROJECT_SAVER2_PDB="$(OUT_DIR_BIN)\$(PROJECT_NAME)ScreenSaver2.pdb"
PROJECT_LIB_PDB="$(OUT_DIR_LIB)\$(PROJECT_NAME)Lib.pdb"
CFLAG_PDB=/Fd
LFLAG_PDB=/PDB:
CFLAG_RUNTIME_STATIC=/MTd
CFLAG_RUNTIME_DLL=/MDd
CFLAGS_COMMON=/Gd /c /W3 /nologo /Od /Zi /RTC1 /Fo"$@"
LFLAGS=/nologo /INCREMENTAL:NO /DEBUG /OUT:"$@"
CFLAGS_DLL=/LDd /D_EXPORTING
!ENDIF

!IFDEF BUILD_STATIC_OBJECT_FILE
! IF $(BUILD_STATIC_OBJECT_FILE)
COMPILE_EXE=$(COMPILE) $(CFLAG_RUNTIME_STATIC) /DBUILD_STATIC_OBJECT_FILE
COMPILE_DLL=$(COMPILE) $(CFLAGS_DLL) $(CFLAG_RUNTIME_STATIC)
PROJECT_LIB_DEP=$(OUT_DIR_BIN)\$(PROJECT_NAME)Lib.obj
! ELSE
COMPILE_EXE=$(COMPILE) $(CFLAG_RUNTIME_DLL)
COMPILE_DLL=$(COMPILE) $(CFLAGS_DLL) $(CFLAG_RUNTIME_DLL)
PROJECT_LIB_DEP=$(OUT_DIR_LIB)\$(PROJECT_NAME).lib
! ENDIF
!ELSE
COMPILE_EXE=$(COMPILE) $(CFLAG_RUNTIME_DLL)
COMPILE_DLL=$(COMPILE) $(CFLAGS_DLL) $(CFLAG_RUNTIME_DLL)
PROJECT_LIB_DEP=$(OUT_DIR_LIB)\$(PROJECT_NAME).lib
!ENDIF


OUT_DIR_BIN=$(BUILD_TYPE)\bin
OUT_DIR_LIB=$(BUILD_TYPE)\lib
COMPILE=$(CPP) $(CFLAGS_COMMON)
LINK=link.exe $(LFLAGS)
MANIFEST=mt -manifest
STANDARD_DEPENDENCY=$(*B).cpp $(*B).h $(MAKEFILE)



all: $(OUT_DIR_BIN)\$(PROJECT_NAME).exe \
$(OUT_DIR_LIB)\$(PROJECT_NAME).lib \
     $(OUT_DIR_BIN)\$(PROJECT_NAME)Cmd.exe \
     $(OUT_DIR_BIN)\$(PROJECT_NAME)ScreenSaver.scr \
$(OUT_DIR_BIN)\$(PROJECT_NAME)ScreenSaver.exe



$(OUT_DIR_LIB)\$(PROJECT_NAME).lib: $*.dll
echo "Was the import library created?"

$(OUT_DIR_LIB)\$(PROJECT_NAME).dll: $*Lib.obj \
                                    $(OUT_DIR_LIB)\ScanNtfs.obj \
$(OUT_DIR_BIN)\$(PROJECT_NAME).res \
$(MAKEFILE)
$(LINK) /dll $(LFLAG_PDB)$(PROJECT_LIB_PDB) \
advapi32.lib \
$*Lib.obj \
$(OUT_DIR_LIB)\ScanNtfs.obj \
$(OUT_DIR_BIN)\$(PROJECT_NAME).res

$(OUT_DIR_LIB)\$(PROJECT_NAME)Lib.obj: $(STANDARD_DEPENDENCY) $(*B)Api.cpp
$(COMPILE_DLL) $(CFLAG_PDB)$(PROJECT_LIB_PDB) $(*B).cpp

$(OUT_DIR_BIN)\$(PROJECT_NAME)Lib.obj: $(STANDARD_DEPENDENCY) $(*B)Api.cpp
$(COMPILE_EXE) $(CFLAG_PDB)$(PROJECT_LIB_PDB) $(*B).cpp

$(OUT_DIR_LIB)\ScanNtfs.obj: $(STANDARD_DEPENDENCY) $(PROJECT_NAME)Lib.h
$(COMPILE_DLL) $(CFLAG_PDB)$(PROJECT_LIB_PDB) $(*B).cpp

$(OUT_DIR_BIN)\ScanNtfs.obj: $(STANDARD_DEPENDENCY) $(PROJECT_NAME)Lib.h
$(COMPILE_EXE) $(CFLAG_PDB)$(PROJECT_EXE_PDB) $(*B).cpp



$(OUT_DIR_BIN)\$(PROJECT_NAME).exe: $*.obj \
                                    $(PROJECT_LIB_DEP) \
                         $(OUT_DIR_BIN)\$(PROJECT_NAME)Common.obj \
                         $(OUT_DIR_BIN)\$(PROJECT_NAME)Log.obj \
                         $(OUT_DIR_BIN)\ScanNtfs.obj \
                         $(OUT_DIR_BIN)\$*.res \
                       $(MAKEFILE)
$(LINK) $(LFLAG_PDB)$(PROJECT_EXE_PDB) \
/LTCG user32.lib gdi32.lib Shell32.lib advapi32.lib \
$*.obj \
$(PROJECT_LIB_DEP) \
$*Common.obj \
$*Log.obj \
$(OUT_DIR_BIN)\ScanNtfs.obj \
$*.res
$(MANIFEST) $(*B).exe.manifest -outputresource:$*.exe;#1

$(OUT_DIR_BIN)\$(PROJECT_NAME).obj: $(*B).cpp $(PROJECT_NAME)Lib.h $(MAKEFILE)
$(COMPILE_EXE) $(CFLAG_PDB)$(PROJECT_EXE_PDB) /GA /GL $(*B).cpp

$(OUT_DIR_BIN)\$(PROJECT_NAME)Common.obj: $(STANDARD_DEPENDENCY)
$(COMPILE_EXE) $(CFLAG_PDB)$(PROJECT_EXE_PDB) $(*B).cpp

$(OUT_DIR_BIN)\$(PROJECT_NAME)Log.obj: $(STANDARD_DEPENDENCY)
$(COMPILE_EXE) $(CFLAG_PDB)$(PROJECT_EXE_PDB) $(*B).cpp



$(OUT_DIR_BIN)\$(PROJECT_NAME)Cmd.exe: $*.obj \
                                       $(PROJECT_LIB_DEP) \
  $(OUT_DIR_BIN)\ScanNtfs.obj \
  $(OUT_DIR_BIN)\$(PROJECT_NAME).res \
  $(MAKEFILE)
$(LINK) $(LFLAG_PDB)$(PROJECT_CMD_PDB) advapi32.lib \
$*.obj \
$(PROJECT_LIB_DEP) \
$(OUT_DIR_BIN)\$(PROJECT_NAME)Log.obj \
$(OUT_DIR_BIN)\ScanNtfs.obj \
$(OUT_DIR_BIN)\$(PROJECT_NAME).res
$(MANIFEST) $(PROJECT_NAME).exe.manifest -outputresource:$*.exe;#1

$(OUT_DIR_BIN)\$(PROJECT_NAME)Cmd.obj: $(*B).cpp $(PROJECT_NAME)Lib.h $(MAKEFILE)
$(COMPILE_EXE) $(CFLAG_PDB)$(PROJECT_CMD_PDB) $(*B).cpp



$(OUT_DIR_BIN)\$(PROJECT_NAME)ScreenSaver.scr: $*1.obj $(PROJECT_NAME).res $(MAKEFILE)
$(LINK) $(LFLAG_PDB)$(PROJECT_SAVER1_PDB) \
/LTCG Shell32.lib advapi32.lib \
$*1.obj \
$(OUT_DIR_BIN)\$(PROJECT_NAME).res

$(OUT_DIR_BIN)\$(PROJECT_NAME)ScreenSaver1.obj: $(*B).cpp $(MAKEFILE)
$(COMPILE_EXE) /GA /GL $(CFLAG_PDB)$(PROJECT_SAVER1_PDB) $(*B).cpp

$(OUT_DIR_BIN)\$(PROJECT_NAME)ScreenSaver.exe: $*2.obj \
                                               $(PROJECT_NAME).res \
  $(PROJECT_LIB_DEP) \
  $(PROJECT_NAME)Common.obj \
  $(PROJECT_NAME)Log.obj \
  $(OUT_DIR_BIN)\ScanNtfs.obj \
  $(MAKEFILE)
$(LINK) $(LFLAG_PDB)$(PROJECT_SAVER2_PDB) \
/LTCG /subsystem:WINDOWS scrnsave.lib \
user32.lib \
gdi32.lib \
Shell32.lib \
advapi32.lib \
comctl32.lib \
Powrprof.lib \
$*2.obj \
$(PROJECT_LIB_DEP) \
$(OUT_DIR_BIN)\$(PROJECT_NAME)Common.obj \
$(OUT_DIR_BIN)\$(PROJECT_NAME)Log.obj \
$(OUT_DIR_BIN)\ScanNtfs.obj \
$(OUT_DIR_BIN)\$(PROJECT_NAME).res

$(OUT_DIR_BIN)\$(PROJECT_NAME)ScreenSaver2.obj: $(*B).cpp $(PROJECT_NAME)Lib.h $(MAKEFILE)
$(COMPILE_EXE) /GA /GL $(CFLAG_PDB)$(PROJECT_SAVER2_PDB) $(*B).cpp

$(OUT_DIR_BIN)\$(PROJECT_NAME).res: $(*B).rc $(*B).ico $(MAKEFILE)
$(RC) -r -fo "$@" $(*B).rc

[elfring]

C programmers will not use the DLL, but embed the sources into their project, because it's easier and removes the need for distributing a DLL with the program. The DLL is only used by programmers using other languages, such as Delphi.

Would you like to support that the DLL interface can also be used by C++ software developers without code embedding?

[jeroen]

How do you think about the following example?

I don't want to offend you, and I appreciate all the time you are putting into JkDefrag, but I think it's a prime example of overengineering. My Makefile is a lot smaller and a lot easier to read.

Would you like to support that the DLL interface can also be used by C++ software developers without code embedding?

I don't see any need for it, because I think nobody will do that, like I explained before.

[elfring]

My Makefile is a lot smaller and a lot easier to read.

I've got doubts about its correctness because of missing compiler switches for DLL generation. I guess that a few more parameters are required to be "absolutely" safe.
The source file dependencies can also be improved.

I don't see any need for it, because I think nobody will do that, like I explained before.

Would any C++ programmer contribute an opinion here? :wink:

[jeroen]

I've got doubts about its correctness because of missing compiler switches for DLL generation.

Which compiler switches?

I guess that a few more parameters are required to be "absolutely" safe.

Which parameters?

The source file dependencies can also be improved.

Which dependencies?

[elfring]

Which compiler switches?

/LD (⇒ /D_DLL)

Which parameters?

/D_EXPORTING (I guess that not all functions should be exported by the library. Some functions are only needed for the internal implementation.)

Which dependencies?

Code:

$(OUT_DIR_LIB)\$(PROJECT_NAME)Lib.obj: $(STANDARD_DEPENDENCY) ScanNtfs.h $(*B)Api.cpp
$(COMPILE_DLL) $(CFLAG_PDB)$(PROJECT_LIB_PDB) $(*B).cpp

$(OUT_DIR_BIN)\$(PROJECT_NAME)Lib.obj: $(STANDARD_DEPENDENCY) ScanNtfs.h $(*B)Api.cpp
$(COMPILE_EXE) $(CFLAG_PDB)$(PROJECT_LIB_PDB) $(*B).cpp

Autotools would detect most of the required files automatically.

[jeroen]

/LD (⇒ /D_DLL)

This compiler switch will define the "DLL" preprocessor symbol, and when the compiler is finished it will call the linker with the "/dll" switch. But my C code does not use the "DLL" symbol anywhere, and the linker is not called by the compiler (but by the Makefile). So this compiler switch is not needed. You can try it for yourself, with and without this switch in my Makefile the results are bit for bit the same.

/D_EXPORTING

My code does not use the "EXPORTING" preprocessor symbol anywhere.

Code:

$(OUT_DIR_LIB)\$(PROJECT_NAME)Lib.obj: $(STANDARD_DEPENDENCY) ScanNtfs.h $(*B)Api.cpp
$(COMPILE_DLL) $(CFLAG_PDB)$(PROJECT_LIB_PDB) $(*B).cpp

$(OUT_DIR_BIN)\$(PROJECT_NAME)Lib.obj: $(STANDARD_DEPENDENCY) ScanNtfs.h $(*B)Api.cpp
$(COMPILE_EXE) $(CFLAG_PDB)$(PROJECT_LIB_PDB) $(*B).cpp

I prefer to explicitly specify the dependencies, instead of using an automatic catchall such as this. It results in smaller binaries (linker optimization does not always catch everything), and provides greater flexibility within a project to generate completely different things, such as a screensaver, a dll, a commandline version, and a windows version, all from the same sources and with a single Makefile.

[elfring]

But my C code does not use the "DLL" symbol anywhere, and the linker is not called by the compiler (but by the Makefile).

Can you imagine that it might make a difference for any other source file from the include hierarchy (Microsoft Runtime Library ...)?

My code does not use the "EXPORTING" preprocessor symbol anywhere.

Your header "JkDefragLib.h" will not be usable by other C/C++ projects to import its functions. You explained that you do not care for such usage so far. :?