Hi,
I've written a program for statistic analysis that can be found here
http://staff.pubhealth.ku.dk/~ande/web/software/relate.html

I want to make it portable and the program works on unix with the following compilers
sun, intel and gcc
It also compiles on windows with mingw and the intel compiler.

I've installed ms studio,
but I have yet to find a sort of Makefile way of installing the program.

Can anyone give me an advice on how to make the compilation step easier for the end windows user.

Do I have to install cmake to generate an msproject/workspace or whatever it's called?
It seems like an overkill just for 8 compilations and 2 times linking.

I mostly an unix user, and most of the window stuff just puzzles me.

Just the commandpromt. I cant even change the width of this.
So when I type in commands with long dir names it spans over multiple lines.

but also the object files aren't called .o under windows,
so what I do is to compile manually with something like

cl -c myfile.cpp

Has anyone any experience with this?

thanks in advance

btw this is my makefile

CC=g++
C=gcc



#this is the flags used for dev.
flags=-ggdb -Wall -pedantic -ansi 

#flags= -O2 -pg

#this is the flag used for prod.
#flags=-O3

all : relateHMM.o relateHMMRun HMMtest


bfgs.o : bfgs.c bfgs.h types.h
	$(C) -c -fPIC -std=gnu99 -O2  bfgs.c 

alloc.o : alloc.h alloc.cpp types.h
	$(CC) -c -fPIC   alloc.cpp ${flags}

ld.o : ld.cpp ld.h types.h
	$(CC)  -c -fPIC  ld.cpp ${flags}

asort.o : asort.cpp asort.h types.h alloc.o
	$(CC) -c asort.cpp ${flags}

filereader_and_conversions.o : filereader_and_conversions.cpp filereader_and_conversions.h types.h
	$(CC) -c filereader_and_conversions.cpp ${flags}

extractors.o : extractors.cpp extractors.h types.h
	$(CC) -c extractors.cpp ${flags}

relateHMM.o:  relateHMM.cpp relateHMM.h ld.o alloc.o asort.o types.h filereader_and_conversions.o extractors.o
	$(CC) -c -fPIC  relateHMM.cpp  ${flags}


relateHMMRun : relateHMM.o runRelate.cpp relateHMM.o bfgs.o alloc.o ld.o asort.o filereader_and_conversions.o types.h extractors.o
	$(CC) -o relateHMM runRelate.cpp asort.o relateHMM.o bfgs.o alloc.o ld.o filereader_and_conversions.o extractors.o ${flags}

HMMtest : HMMtest.cpp alloc.o types.h
	$(CC) -o HMMtest HMMtest.cpp alloc.o ${flags} 

makeR: HMMld.cpp relateHMM.o bfgs.o ld.o 
	R CMD SHLIB HMMld.cpp relateHMM.o bfgs.o alloc.o ld.o 

clean:
	rm  -f *.o  relateHMM Relate.so HMMtest

Dani AI

Generated

Short summary and practical options based on the replies: is right that keeping separate Windows/Unix build descriptions works; and pointed out the Windows-native route (MSBuild/.sln); linked Microsoft docs. Below are pragmatic, low-friction choices ranked by what an end user or a maintainer typically prefers.

For end users: produce and ship Windows binaries (zip or installer). Build once on a Windows machine or CI (AppVeyor/GitHub Actions runners), bundle the required runtime (Visual C++ redistributable if built with MSVC) and a tiny README. For the R target, build a Windows R binary with Rtools rather than asking users to install a full toolchain (Rtools page: https://cran.r-project.org/bin/windows/Rtools/).

For maintainability: adopt CMake. A single CMakeLists.txt can generate Visual Studio solutions, MinGW makefiles or Ninja files so you only list sources once. CMake will pick the correct object suffixes and platform flags for you. Minimal example (replace names with your sources):

cmake_minimum_required(VERSION 3.10)
project(MyProject C CXX)
file(GLOB SRC RELATIVE ${CMAKE_SOURCE_DIR} src/*.c src/*.cpp)
add_library(mylib SHARED ${SRC})
add_executable(myexe tools/run.cpp)
target_link_libraries(myexe PRIVATE mylib)

Then run a generator like cmake -G "Visual Studio 16 2019" .. or cmake -G "MinGW Makefiles" ... CMake docs: https://cmake.org/

If you want zero new tools: keep a tiny Windows build script (batch/PowerShell) for MinGW users, or create a Visual Studio project and let Windows users build with the Developer Command Prompt / MSBuild. Microsoft MSBuild docs: https://learn.microsoft.com/visualstudio/msbuild/msbuild

Quick tips and pitfalls:

  • Windows object files are typically .obj, Unix .o; use a build system (CMake or conditional Makefiles) to avoid hand-editing names.
  • DLL versus .so differences and import libs (.lib/.a) affect linking order — build and test on Windows CI.
  • If you prefer to stay in a Unix-like toolchain on Windows, suggest WSL or MinGW to users.

These approaches let you keep one authoritative source of truth while giving simple options for both end users and developers.

Recommended Answers

All 4 Replies

I don't think you will be able to use the same makefile across UNIX and Windows. What you can do is have 2 makefiles with different extensions like makefile.XP and makefile.Sun and have another sort of a base makefile included in all the makefiles that decides at compile time which of the above makefiles to pick based on env variables like OS_REV, which should be set in the env. file.

Something on these lines might help.

Microsoft stopped supporting makefiles beginning with VC++ 2005. Instead they have solution files which you can use to do command-line compiles. But first you will have to use the IDE to create the solution file. It also has its own version of make, but I don't recall its name.

but I don't recall its name.

That would be MSBuild

Always MS-something when it's microsoft, just as it's always mc-something with mc-donalds ;)

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.