DJ_AM_Juicebox
asked on
vc++ project to linux
Hi,
I wrote a decently sized set of applications under win32 using vc++ 2005. None of the applications are GUIs, they're all just plain old console applications. I also made sure to wrap all win32 system calls in a library like:
void HelperLibrary::CreateProce
{
#ifdef WIN32
// .. call win api function to create a process.
#else
// .. linux equivalent
#endif
}
yeah so i took special care to do all of that.
I put all my source code into subversion so it's all source controlled. I was hoping I could stick the same exact files onto a linux system and compile the project as is. But what will happen with all the vc++ specific files like the .sln file etc? How would I even begin compiling these projects under linux - i'd have to bring them all into some editor and tell each project whether it is a static library or an executable, etc.
Where do I start?
Thanks
I wrote a decently sized set of applications under win32 using vc++ 2005. None of the applications are GUIs, they're all just plain old console applications. I also made sure to wrap all win32 system calls in a library like:
void HelperLibrary::CreateProce
{
#ifdef WIN32
// .. call win api function to create a process.
#else
// .. linux equivalent
#endif
}
yeah so i took special care to do all of that.
I put all my source code into subversion so it's all source controlled. I was hoping I could stick the same exact files onto a linux system and compile the project as is. But what will happen with all the vc++ specific files like the .sln file etc? How would I even begin compiling these projects under linux - i'd have to bring them all into some editor and tell each project whether it is a static library or an executable, etc.
Where do I start?
Thanks
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Sorry just correcting my previous sentence.
As jkr suggests you can first go through the Make Tutorial.Initially writing a Makefile will be very difficult because even the spaces between the charcters and commands inside a Makefile are very important when you write a make file.
As jkr suggests you can first go through the Make Tutorial.Initially writing a Makefile will be very difficult because even the spaces between the charcters and commands inside a Makefile are very important when you write a make file.
>>>> will happen with all the vc++ specific files like the .sln file etc?
The .sln file is a minor file which has a reference to the project file (.vcproj) and some dependencies if more than one project is in the solution. The file which is more important is the .vcproj file as it has the same purpose as a LINUX Makefile.
If you name your makefile 'Makefile' and put it into your LINUX project folder, you simply can type 'make' in order to invoke the makefile. If your project has a few files only and not much libraries, you may look for *any* makefile coming with a tutorial or a sample project, copy it to the project folder where the sources are, and replace the target (file)names and folders in the makefile. I always used to edit in the Visual Studio and transfered to the UNIX after but that may be simply cause I didn't know a suitable editor on the UNIX side. Be aware that LINUX is case sensitive. You best make all filenames (in include statements as well!) lower case *prior* to moving the files to UNIX. I always tried to have *one* source only and make changes only at one system.
Regards, Alex
The .sln file is a minor file which has a reference to the project file (.vcproj) and some dependencies if more than one project is in the solution. The file which is more important is the .vcproj file as it has the same purpose as a LINUX Makefile.
If you name your makefile 'Makefile' and put it into your LINUX project folder, you simply can type 'make' in order to invoke the makefile. If your project has a few files only and not much libraries, you may look for *any* makefile coming with a tutorial or a sample project, copy it to the project folder where the sources are, and replace the target (file)names and folders in the makefile. I always used to edit in the Visual Studio and transfered to the UNIX after but that may be simply cause I didn't know a suitable editor on the UNIX side. Be aware that LINUX is case sensitive. You best make all filenames (in include statements as well!) lower case *prior* to moving the files to UNIX. I always tried to have *one* source only and make changes only at one system.
Regards, Alex
ASKER
Ok I think what I'll do (since the makefiles look pretty tedious) is get kdevelop on the linux machine and add all the source files to it in a linux project, then add that to source control as well. As long as vc++ ignores the kdevelop files when building on windows, and kdevelop ignores the vc++ files when building for linux, it should be ok right?
Thanks
Thanks
>>>> it should be ok right?
yes, LINUX doesn't care for .vcproj and VS doesn't care for Makefile.
>>>> since the makefiles look pretty tedious
it isn't so difficult if you start with a little test project and examine the makefile. The one you should know is that a makefile goes for 'targets', e. g.
// excerpt of a makefile
# rule(s)
# creates object from source.
.c.o:
$(CC) $(CFLAGS) $<
# target(s), first target is default target
wmvt: $(OBJS)
$(CC) $(CSFLAGS) -o wmvt.so $(EXPCOPT) $(LFLAGS) $(OBJS)
Here you have two targets. The '.c.o' and the 'wmvt' target. The end of a target is the next empty line. It works like a break; in a switch statements.
After a target there can be specified new targets, e. g. the $(OBJS) after wmvt:
The $() evaluates a macro. In OBJS all objectfiles of my project 'wmvt' were listed. If my current target is 'wmvt' the compiler checks if any of the object files is not up-to-date. It does that by applying the above 'rule' .c.o which says that the 'source' for each object file (.o) is the .c file with the same name. If any of the .c files is younger than the corresponding .o file the target will be applied what means that the
$(CC) $(CFLAGS) $<
will be applied for the current objectfile (specified by $<). CC and CFLAGS are macros defined at top of the makefile. CC is the compiler command and CFLAGS the compiler switches and options.
After each object that was not upto-date was built the make would finish the wmvt macro by invoking the
$(CC) $(CSFLAGS) -o wmvt.so $(EXPCOPT) $(LFLAGS) $(OBJS)
what is the linker part of the compiler (in my sample it creates a 'shared object' what is a dll at UNIX using an export list and the list of object files and some special compiler flags in CSFLAGS).
Regards, Alex
yes, LINUX doesn't care for .vcproj and VS doesn't care for Makefile.
>>>> since the makefiles look pretty tedious
it isn't so difficult if you start with a little test project and examine the makefile. The one you should know is that a makefile goes for 'targets', e. g.
// excerpt of a makefile
# rule(s)
# creates object from source.
.c.o:
$(CC) $(CFLAGS) $<
# target(s), first target is default target
wmvt: $(OBJS)
$(CC) $(CSFLAGS) -o wmvt.so $(EXPCOPT) $(LFLAGS) $(OBJS)
Here you have two targets. The '.c.o' and the 'wmvt' target. The end of a target is the next empty line. It works like a break; in a switch statements.
After a target there can be specified new targets, e. g. the $(OBJS) after wmvt:
The $() evaluates a macro. In OBJS all objectfiles of my project 'wmvt' were listed. If my current target is 'wmvt' the compiler checks if any of the object files is not up-to-date. It does that by applying the above 'rule' .c.o which says that the 'source' for each object file (.o) is the .c file with the same name. If any of the .c files is younger than the corresponding .o file the target will be applied what means that the
$(CC) $(CFLAGS) $<
will be applied for the current objectfile (specified by $<). CC and CFLAGS are macros defined at top of the makefile. CC is the compiler command and CFLAGS the compiler switches and options.
After each object that was not upto-date was built the make would finish the wmvt macro by invoking the
$(CC) $(CSFLAGS) -o wmvt.so $(EXPCOPT) $(LFLAGS) $(OBJS)
what is the linker part of the compiler (in my sample it creates a 'shared object' what is a dll at UNIX using an export list and the list of object files and some special compiler flags in CSFLAGS).
Regards, Alex
ASKER
@itsmeandnobodyelse:
I went through the makefile tutorial, I mean it's not horrible, looks easy for smallish projects - but eventually I want the whole project to be developed only for linux anyway. So I'd like to have some IDE to start developing with on linux. If I have KDE solution files (which i assume are just the equivelnt to vc++ more or less) i guess that setup will work fine?
Thanks
I went through the makefile tutorial, I mean it's not horrible, looks easy for smallish projects - but eventually I want the whole project to be developed only for linux anyway. So I'd like to have some IDE to start developing with on linux. If I have KDE solution files (which i assume are just the equivelnt to vc++ more or less) i guess that setup will work fine?
Thanks
Well, Makefiles are pretty much the standard in the UN*X world, even for large projects - e.g. the Linux kernel comes with a Makefile. On the Windows side, VC++ ships with NMAKE, which is pretty much conformant to the BSD 'make' on the UN*X side. Yet I'd also not try to mix the build file for both platforms. NMAKE support has been reduced by MS during ech recent release of VC++.
everything.You only have to keep your .cpp files and Makefile.
As jkr suggests you can first go through the Make Tutorial.Initially writing a Makefile will be very difficult be cause even the spaces between the charcters and commands inside a Makefile are very difficult.
So to do it easily, programmers download some very simple makefiles and analyse that and try adding new commands to that.That is an easy way to start off with your own make file once you are done with the tutorial.