how to crate a make file for verifone (vx520 or vx820)

Question

I have a verifone terminal (vx520 and vx820). I whant to crate a makefile for compile app for this terminal. I have "VRXSDK" version 1.2.0

howto do it?

or how to compile a file like "main.c" or "main.cpp" till have a execute file for verifone POS terminal

Answer 1

Wherever you got your "VRXSDK" from, you should also be able to get some sample project files. You will find a make file in there (likely with a .smk extension). I would recommend you start with that and as you read through it, that should give you more specific questions to ask and things you can look up using your favorite search engine.

A make file is, in essence, a program that invokes the compiler with input parameters you determine based on various factors. It will also invoke the linker to tie it all together. How you go about this varies wildly from one implementation to another, so "How do I create a make file" is just about as broad as "how do I write a program?" which makes answering it here rather challenging. However, to get you started...

I use Visual Studio as my IDE and I am using NMake. I actually have 2 layers of make files. The outer layer is what is called when I say "build" from my IDE and it is very short:

# Pick one of the following (for LOG_PRINTF messages)
#CompileWithLogSys = -DLOGSYS_FLAG 
CompileWithLogSys =

all:
    $(MAKE) /i /f coreBuild.smk /a TerminalType=$(Configuration) CompileWithLogSys=$(CompileWithLogSys) VMACMode=Multi
    $(MAKE) /i /f coreBuild.smk /a TerminalType=$(Configuration) CompileWithLogSys=$(CompileWithLogSys) VMACMode=Single

Lines starting with # are comments.

This outer file makes it really easy for me to toggle a few things when I want to build different variations. You can see that I have turned OFF compliation with LogSys. The more important thing the 2-layer approach gives me is an easy way to compile 2 different versions with a single command to build. This runs nmake with "VMACMode" set to "Multi" and then runs it again with it set to "Single". The inner make file will see that parameter and compile to a different root folder for each so in the end I wind up with 2 folders, each with a different version.

You can do a web search on "nmake parameters" to see what things like /i and /f do, as well as other options I'm not using here. However, I would like to direct your attention to TerminalType=$(Configuration) . In Visual Studio, you can select from a dropbox if you want "Debug" or "Release". Those 2 options are the default options, but you can change them; in my case, I have modified them to "eVo" and "Vx". Now I just select in my drop down box which version I want to compile for and that gets passed in. Alternately, I could just hard code both into my outer make file. That's just preference.

My inner make file (which is named "coreBuild.smk") gets much more interesting. Generally, you start by defining variables, such as "include paths":

# Includes
SDKIncludes = -I$(EVOSDK)\include
ACTIncludes = -I$(EVOACT)include
VCSIncludes = -I$(EVOVCS)include
EOSIncludes = -I$(EOSSDK)\include\ssl2

And/Or libraries:

#Libraries
ACTLibraries    = $(EVOACT)OutPut\RV\Files\Static\Release

#Others you may want to include, but I am not using:
#LOGSYSLibraries = $(EVOVMAC)\Output\RV\Lib\Files\Debug
#EOSLibraries   = $(EOSSDK)\lib

As well as the path(s) to your files

#  App Paths
AppIncludes = .\include
SrcDir      = .\source
ObjDir      = .\obj
OutDir      = .\Output\$(TerminalType)\$(VMACMode)\Files
ResDir      = .\Resource

I also like to define my project name here:

ProjectName = MakeFileTest

Note that OutDir uses the TerminalType and VMACMode that we passed in in order to go to a unique folder.

Next, you would generally set your compiler options

#   Compiler Options
#  Switch based on terminal type
!IF "$(TerminalType)"=="eVo"
CompilerCompatibility=-p
DefineTerminalType = -DEVO_TERMINAL
!ELSE
CompilerCompatibility=
DefineTerminalType = -DVX_TERMINAL
!ENDIF

#  Switch based on Multi or Single mode (VMACMode)
!if "$(VMACMode)"=="Multi"
VMACIncludes = -I$(EVOVMAC)include
DefineMulti = -DMULTI_APP_ENABLED
!else
VMACIncludes = 
DefineMulti = 
!endif

An interesting thing to note above is the -DMULTI_APP_ENABLED . The program I wrote has some blocks that are dependent on #ifdef MULTI_APP_ENABLED . This is not any special name--it's just one I came up with, but the compiler will define it right before it starts compiling my code, so I can turn those code blocks on and off right here.

Next, we are going to kinda' gather everything together. We will start by defining a new var, "Includes" and it will have the flag "-I" (to indicate "include" and then all the things we said above that we wanted to include:

Includes    = -I$(AppIncludes) $(SDKIncludes) $(ACTIncludes) $(VMACIncludes) $(VCSIncludes)

Note that you could just type everything long hand here and not go through the extra steps of defining the vars in the first place, but it makes it easier to read, so I think this is pretty normal.

We do pretty much the same thing with compiler options, although note that the specific flags (ex, "-D" "-p") were already included in the original var declarations, so we leave them out here:

COptions    =$(CompilerCompatibility) $(CompileWithLogSys) $(DefineTerminalType) $(DefineMulti) -DDEV_TOGGLES_FOR_SYNTAX 

Next we set a variable that will tell the linker where the object files are that it needs to stitch together. Note that if you insert new lines, as I have, you need the '\\' to tell it that it continues on the next line

# Dependencies
AppObjects = \
        $(ObjDir)\$(ProjectName).o \
        $(ObjDir)\Base.o \
        $(ObjDir)\printer.o \
        $(ObjDir)\UI.o \
        $(ObjDir)\Comm.o

We will also set one for any libaries we want to link in:

Libs = $(ACTLibraries)\act2000.a

OK, next we have to sign the file(s). We are trying to tell nMake that we also will be creating the resource file and compiling the actual code. If we are doing a multi-app build, then pseudoOut depends on the .res and the .out files. If not, then it just depends on the .out, because there is no .res. If the the dependent file(s) has/have changed more recently than pseudoOut, then run commands vrxhdr..., filesignature..., and move... NOTE that the indentations seen below are required for nMake to work properly.

!if "$(VMACMode)"=="Multi"
pseudoOut : $(ResDir)\$(ProjectName).res $(OutDir)\$(ProjectName).out
!else
pseudoOut : $(OutDir)\$(ProjectName).out 
!endif
#   This calls vrxhdr: the utility program that fixes the executable program’s header required to load and run the program. Vrxhdr is needed when you want to move a shared library around on the terminal.
    $(EVOSDK)\bin\vrxhdr -s 15000 -h 5000 $(OutDir)\$(ProjectName).out

# do the signing using the file signature tool and the .fst file associated with this TerminalType.
    "$(VSFSTOOL)\filesignature" $(TerminalType)$(VMACMode).fst -nogui
    @echo __________________ move files to out directory __________________
# rename the .p7s file we just created 
    move $(OutDir)\$(ProjectName).out.p7s $(OutDir)\$(ProjectName).p7s

!if "$(VMACMode)"=="Multi"
    copy $(ResDir)\imm.ini $(OutDir)\imm.ini
    copy $(ResDir)\$(ProjectName).INS $(OutDir)\$(ProjectName).INS
    copy $(ResDir)\$(ProjectName).res $(OutDir)\$(ProjectName).res
!endif
    @echo *****************************************************************

Note that the "echo" commands are just to help me read my output logs, as needed.

OK, now we link.

"WAIT!" I can hear you saying, "We haven't compiled yet, we already issued a command to sign, and now we are linking? This is totally out of order!" Yes and no. We haven't actually issued the command to sign yet, we have merely told nmake that we may want to do that and how to do it if we decide so to do. Similarly, we aren't issuing the command to link yet, we are just telling nmake how to do it when we are ready.

#  Link object files
$(OutDir)\$(ProjectName).out : $(AppObjects)
    $(EVOSDK)\bin\vrxcc $(COptions) $(AppObjects) $(Libs) -o $(OutDir)\$(ProjectName).out

Remember that mutli-app programs need a .res file. Single apps don't. The following will actually build the .res file, as needed.

!if "$(VMACMode)"=="Multi"
#  compile resource file
$(ResDir)\$(ProjectName).res : $(ResDir)\$(ProjectName).rck
    $(EVOTOOLS)rck2 -S$(ResDir)\$(ProjectName) -O$(ResDir)\$(ProjectName) -M
!endif

Remember those AppObjects? We are finally ready to make them. I'm using the following flags

• -c = compile only
• -o = output file name
• -e"-" => -e redirect error output from sub-tools to... "-" to stdout. (These are all then redirected via pipe | )

Again, wherever you got your VRXSDK, you should also be able to get some documentation from VeriFone. See "Verix_eVo_volume 3", page 59 for more details on the flags

$(ObjDir)\$(ProjectName).o : $(SrcDir)\$(ProjectName).c
!IF !EXISTS($(OutDir))
    !mkdir $(OutDir)
!ENDIF
    -$(EVOSDK)\bin\vrxcc -c $(COptions) $(Includes) -o $(ObjDir)\$(ProjectName).o $(SrcDir)\$(ProjectName).c -e"-" | "$(EVOTOOLS)fmterrorARM.exe"

$(ObjDir)\Base.o : $(SrcDir)\Base.c 
  $(EVOSDK)\bin\vrxcc -c $(COptions) $(Includes) -o $(ObjDir)\base.o $(SrcDir)\Base.c -e"-" | "$(EVOTOOLS)fmterrorARM.exe"

$(ObjDir)\myprinter.o : $(SrcDir)\printer.c 
  $(EVOSDK)\bin\vrxcc -c $(COptions) $(Includes) -o $(ObjDir)\printer.o $(SrcDir)\printer.c -e"-" | "$(EVOTOOLS)fmterrorARM.exe"

$(ObjDir)\UI.o : $(SrcDir)\UI.c 
  $(EVOSDK)\bin\vrxcc -c $(COptions) $(Includes) -o $(ObjDir)\UI.o $(SrcDir)\UI.c -e"-" | "$(EVOTOOLS)fmterrorARM.exe"

$(ObjDir)\Comm.o : $(SrcDir)\Comm.c 
  $(EVOSDK)\bin\vrxcc -c $(COptions) $(Includes) -o $(ObjDir)\Comm.o $(SrcDir)\Comm.c -e"-" | "$(EVOTOOLS)fmterrorARM.exe"