Jump to content
Visual Boy Advance-M

Recommended Posts

I noticed the Makefile was deleted. How does one build the following?

 

VBA-M SDL for UNIX from UNIX

VBA-M SDL for UNIX from UNIX using x86 assembly

VBA-M SDL for Windows from Windows

VBA-M SDL for Windows from UNIX

 

Thanks.

Share this post


Link to post
Share on other sites

So, to build VBA-M SDL from Unix :

In the source code tree, run :

cmake .

make

make install

 

The ASM core can't be built from Unix, because the asm code is not compatible with newer GCCs. However, the ASM scalers will be used if nasm is found.

 

To build VBA-M SDL from Windows, you have to use a msys environment (with all the dependencies), and install cmake from http://www.cmake.org/

Then it builds exactly the same way as under Unix

 

You can't build VBA-M SDL with the ASM core from Windows, that's a limitation of the cmake script. I'll try to fix that.

 

I can restore the old Makefile if you want.

Share this post


Link to post
Share on other sites

The ASM core can't be built from Unix, because the asm code is not compatible with newer GCCs. However, the ASM scalers will be used if nasm is found.

So if NASM is found, it will link HQXx in assembly, and otherwise C? I can't have fine control of that? (I regularly have systems with NASM installed that aren't x86, or situations where it is x86, but I want to test without it).

 

To build VBA-M SDL from Windows, you have to use a msys environment (with all the dependencies), and install cmake from http://www.cmake.org/

Then it builds exactly the same way as under Unix

I find that to be ridiculous :ashamed:

 

You also didn't answer the last question:

 

VBA-M SDL for Windows from UNIX

Share this post


Link to post
Share on other sites

The ASM core can't be built from Unix, because the asm code is not compatible with newer GCCs. However, the ASM scalers will be used if nasm is found.

So if NASM is found, it will link HQXx in assembly, and otherwise C? I can't have fine control of that? (I regularly have systems with NASM installed that aren't x86, or situations where it is x86, but I want to test without it).

I'm sorry, I was mistaken, the ASM scalers will only be used if you call cmake with :

cmake USEASM=1 .

 

To build VBA-M SDL from Windows, you have to use a msys environment (with all the dependencies), and install cmake from http://www.cmake.org/

Then it builds exactly the same way as under Unix

I find that to be ridiculous :ashamed:

I'm sorry if it is the standard way to build Unix programs under Windows. Most programs use the autotools wich require msys. I consider cmake as just another package for mingw.

 

You also didn't answer the last question:

VBA-M SDL for Windows from UNIX

I'm no specialist of cross compilation. I guess it can be done in a similar way to the old Makefile.

Share this post


Link to post
Share on other sites

I'm sorry, I was mistaken, the ASM scalers will only be used if you call cmake with :

cmake USEASM=1 .

Okay, thank you.

 

To build VBA-M SDL from Windows, you have to use a msys environment (with all the dependencies), and install cmake from http://www.cmake.org/

Then it builds exactly the same way as under Unix

I find that to be ridiculous :ashamed:

I'm sorry if it is the standard way to build Unix programs under Windows. Most programs use the autotools wich require msys. I consider cmake as just another package for mingw.

We didn't require autotools or msys to build the SDL port on Windows before. I don't mind requiring cmake, but if we're requiring cmake, and it needs to be used through msys, I think that is getting out of hand.

 

You also didn't answer the last question:

VBA-M SDL for Windows from UNIX

I'm no specialist of cross compilation. I guess it can be done in a similar way to the old Makefile.

So can we setup cross compilation somehow with cmake? Because I have no idea how to use cmake. It just means we have to change the calls to GCC and NASM, and a couple of flags.

Share this post


Link to post
Share on other sites

We didn't require autotools or msys to build the SDL port on Windows before. I don't mind requiring cmake, but if we're requiring cmake, and it needs to be used through msys, I think that is getting out of hand.

Oh, I just thought about it: you can generate VS projects using cmake. It has a nice GUI for Windows to do so. I've not tested it though.

 

So can we setup cross compilation somehow with cmake? Because I have no idea how to use cmake. It just means we have to change the calls to GCC and NASM, and a couple of flags.

I just found that :

http://www.cmake.org/Wiki/CMake_Cross_Compiling

It looks like all you have to do is creating a "toolchain file" corresponding to the target platform.

Share this post


Link to post
Share on other sites

We didn't require autotools or msys to build the SDL port on Windows before. I don't mind requiring cmake, but if we're requiring cmake, and it needs to be used through msys, I think that is getting out of hand.

Oh, I just thought about it: you can generate VS projects using cmake. It has a nice GUI for Windows to do so. I've not tested it though.

Last thing I want is a VS project. I'd like a Makefile for MinGW, and a Makefile for cl.exe

 

So can we setup cross compilation somehow with cmake? Because I have no idea how to use cmake. It just means we have to change the calls to GCC and NASM, and a couple of flags.

I just found that :

http://www.cmake.org/Wiki/CMake_Cross_Compiling

It looks like all you have to do is creating a "toolchain file" corresponding to the target platform.

Can you give me a hand in making such a thing?

Share this post


Link to post
Share on other sites

Well, I went to install cmake, 20MB, why so huge?

 

Well, I just tried to edit this, I made these changes:

 

Index: CMakeLists.txt
===================================================================
--- CMakeLists.txt      (revision 557)
+++ CMakeLists.txt      (working copy)
@@ -3,6 +3,12 @@
INCLUDE(CMakeScripts/CMakeDetermineASMCompiler.cmake)
INCLUDE(CMakeScripts/CMakeASMInformation.cmake)

+IF ( WINCROSS )
+    SET( CMAKE_C_COMPILER i586-mingw32-gcc )
+    SET( CMAKE_CXX_COMPILER i586-mingw32-g++ )
+    SET( WIN32 1 )
+ENDIF ( WINCROSS )
+
PROJECT(VBA-M ASM C CXX)

FIND_PACKAGE ( ZLIB REQUIRED )
@@ -44,7 +50,11 @@

ADD_DEFINITIONS (-DVERSION='"${VERSION}"' -DPKGDATADIR='"${PKGDATADIR}"' -DPACKAGE='')

-SET( CMAKE_ASM_FLAGS "-Isrc/hq/asm/ -O1 -DELF")
+IF ( WIN32 )
+    SET( CMAKE_ASM_FLAGS "-Isrc/hq/asm/ -O1")
+ELSE ( WIN32 )
+    SET( CMAKE_ASM_FLAGS "-Isrc/hq/asm/ -O1 -DELF")
+ENDIF ( WIN32 )
SET( CMAKE_C_FLAGS "-O3 -Wall")
SET( CMAKE_CXX_FLAGS "-O3 -Wall")

And ran with "cmake WINCROSS=1 .", and it still builds the exact same file. It's not using the compilers I told it to.

 

Furthermore, is there anyway I can see what it's actually doing? This percentage thing instead of build commands is EXTREMELY annoying.

Share this post


Link to post
Share on other sites

To display all the commands :

make VERBOSE=1

(set CMAKE_VERBOSE_MAKEFILE to 1 to enable it by default)

 

To pass an argument :

cmake -DWINCROSS=1 .

 

To generate a MinGW Makefile :

cmake -G "MinGW Makefiles" .

 

To generate a NMake Makefile :

cmake -G "NMake Makefile" .

Share this post


Link to post
Share on other sites

Okay, I changed how I ran cmake, it's still using /usr/bin/c++ as opposed to i586-mingw32-g++, why is this? Thanks for the other info.

Share this post


Link to post
Share on other sites

I found that if I delete the CMakeFiles directory, and run "cmake -DWINCROSS=1 ." again, it works now. Is there an official method to delete that directory, like "make distclean" or something?

 

Also, is there perhaps the possibility that we can have different parameters like that perhaps create a CMakeFiles-win directory and Makefile.win, so I can have both UNIX and Windows builds at the same time?

 

I also found an issue, it's using the wrong ar and ranlib in the process. How do I override those so it uses the proper ones?

It's also doing this in the final step:

-o vbam -rdynamic -L/home/nach/SVN/vbam/trunk libvbamcore.a -lSDL -lz -lpng -lGLU -lGL -lSM -lICE -lX11 -lXext

This should be vbam.exe, and not be linking in -lSM -lICE -lX11 -lXext, nor using -rdynamic. How can I get rid of these?

 

There's also a problem with the assembly or something here.

It's doing this:

/usr/bin/nasm -f elf -Isrc/hq/asm/ -O1 -DELF -I/usr/include/SDL   -DSYSCONFDIR='"/etc"' -DVERSION='"1.8.0-SVN"' -DPKGDATADIR='"/usr/local/share/vbam"' -DPACKAGE='' -o CMakeFiles/vbam.dir/src/hq/asm/hq4x_32.o /home/nach/SVN/vbam/trunk/src/hq/asm/hq4x_32.asm

ELF should not be used in Windows mode.

 

I specifically have:

IF ( WIN32 )
   SET( CMAKE_ASM_FLAGS "-Isrc/hq/asm/ -O1")
ELSE ( WIN32 )
   SET( CMAKE_ASM_FLAGS "-Isrc/hq/asm/ -O1 -DELF")
ENDIF ( WIN32 )

 

And the included NASM build rules also has win32 specified as follows:

       IF(WIN32)
               SET(CMAKE_ASM_COMPILE_OBJECT " -f win32 -DWIN32  -o  -c ")
       ENDIF(WIN32)

But the -DWIN32 and all isn't appearing.

Share this post


Link to post
Share on other sites

So I did some more digging and fixes, set a few more variables. Now for "ar", it's running "cr", any ideas what's going on? I check the cache, and I see these:

 

########################
# EXTERNAL cache entries
########################

//Path to a program.
CMAKE_AR:FILEPATH=

//ASM compiler.
CMAKE_ASM_COMPILER:FILEPATH=/usr/bin/nasm

//CXX compiler.
CMAKE_CXX_COMPILER:FILEPATH=/var/chroot/sid-ia32/usr/i586-mingw32/bin/i586-mingw32-g++

//Path to a program.
CMAKE_CXX_COMPILER_WITH_PATH:FILEPATH=/var/chroot/sid-ia32/usr/i586-mingw32/bin/i586-mingw32-g++

//C compiler.
CMAKE_C_COMPILER:FILEPATH=/var/chroot/sid-ia32/usr/i586-mingw32/bin/i586-mingw32-gcc

//Path to a program.
CMAKE_C_COMPILER_WITH_PATH:FILEPATH=/var/chroot/sid-ia32/usr/i586-mingw32/bin/i586-mingw32-gcc

//Path to a program.
CMAKE_LINKER:FILEPATH=

//Path to a program.
CMAKE_MAKE_PROGRAM:FILEPATH=/usr/bin/make

//Path to a program.
CMAKE_NM:FILEPATH=

//Path to a program.
CMAKE_OBJCOPY:FILEPATH=

//Path to a program.
CMAKE_OBJDUMP:FILEPATH=

//Path to a program.
CMAKE_STRIP:FILEPATH=

 

If you check latest SVN, you'll see that I setup ar, ld and friends, yet only my C and C++ changes seem to be working. Any ideas?

 

Also, this having to delete the cache file and directories and Makefile is getting annoying each time, is there a clean command?

Share this post


Link to post
Share on other sites

So I did some more digging and fixes, set a few more variables. Now for "ar", it's running "cr", any ideas what's going on? I check the cache, and I see these:

...

 

What's in your CMakeFiles/vbamcore.dir/link.txt?

Mine starts "/usr/bin/ar cr libvbamcore.a " ...

Maybe you actually set the AR program to empty string somewhere (hint: line 1: "CMAKE_AR:FILEPATH=" and nothing else .. and of course my cache has "CMAKE_AR:FILEPATH=/usr/bin/ar", but I didn't "rerun [rm -rf CMakeFiles CMakeCache.txt]" cmake yet ...)?

 

 

As for applying changed CMakeLists.txt ... tough luck ... it is *supposed* to be hand-editable. How would cmake now which parts were hand-edited and which of those it should keep?

Just delete.

Or run cmake from a different build directory every time :(

Share this post


Link to post
Share on other sites

So I did some more digging and fixes, set a few more variables. Now for "ar", it's running "cr", any ideas what's going on? I check the cache, and I see these:

...

 

What's in your CMakeFiles/vbamcore.dir/link.txt?

 

cr libvbamcore.a  CMakeFiles/vbamcore.dir/src/2xSaI.obj CMakeFiles/vbamcore.dir/src/admame.obj CMakeFiles/vbamcore.dir/src/armdis.obj CMakeFiles/vbamcore.dir/src/bilinear.obj CMakeFiles/vbamcore.dir/src/bios.obj CMakeFiles/vbamcore.dir/src/Cheats.obj CMakeFiles/vbamcore.dir/src/CheatSearch.obj CMakeFiles/vbamcore.dir/src/EEprom.obj CMakeFiles/vbamcore.dir/src/elf.obj CMakeFiles/vbamcore.dir/src/Flash.obj CMakeFiles/vbamcore.dir/src/Globals.obj CMakeFiles/vbamcore.dir/src/interframe.obj CMakeFiles/vbamcore.dir/src/hq2x.obj CMakeFiles/vbamcore.dir/src/Mode0.obj CMakeFiles/vbamcore.dir/src/Mode1.obj CMakeFiles/vbamcore.dir/src/Mode2.obj CMakeFiles/vbamcore.dir/src/Mode3.obj CMakeFiles/vbamcore.dir/src/Mode4.obj CMakeFiles/vbamcore.dir/src/Mode5.obj CMakeFiles/vbamcore.dir/src/pixel.obj CMakeFiles/vbamcore.dir/src/remote.obj CMakeFiles/vbamcore.dir/src/RTC.obj CMakeFiles/vbamcore.dir/src/scanline.obj CMakeFiles/vbamcore.dir/src/Sound.obj CMakeFiles/vbamcore.dir/src/Sram.obj CMakeFiles/vbamcore.dir/src/Util.obj CMakeFiles/vbamcore.dir/src/expr.obj CMakeFiles/vbamcore.dir/src/exprNode.obj CMakeFiles/vbamcore.dir/src/expr-lex.obj CMakeFiles/vbamcore.dir/src/memgzio.obj CMakeFiles/vbamcore.dir/src/agb/agbprint.obj CMakeFiles/vbamcore.dir/src/agb/GBA.obj CMakeFiles/vbamcore.dir/src/agb/gbafilter.obj CMakeFiles/vbamcore.dir/src/agb/GBAGfx.obj CMakeFiles/vbamcore.dir/src/agb/GBA-thumb.obj CMakeFiles/vbamcore.dir/src/agb/GBA-arm.obj CMakeFiles/vbamcore.dir/src/dmg/GB.obj CMakeFiles/vbamcore.dir/src/dmg/gbCheats.obj CMakeFiles/vbamcore.dir/src/dmg/gbDis.obj CMakeFiles/vbamcore.dir/src/dmg/gbGfx.obj CMakeFiles/vbamcore.dir/src/dmg/gbGlobals.obj CMakeFiles/vbamcore.dir/src/dmg/gbMemory.obj CMakeFiles/vbamcore.dir/src/dmg/gbPrinter.obj CMakeFiles/vbamcore.dir/src/dmg/gbSGB.obj CMakeFiles/vbamcore.dir/src/dmg/gbSound.obj CMakeFiles/vbamcore.dir/src/dmg/gb_apu/Blip_Buffer.obj CMakeFiles/vbamcore.dir/src/dmg/gb_apu/Effects_Buffer.obj CMakeFiles/vbamcore.dir/src/dmg/gb_apu/Gb_Apu.obj CMakeFiles/vbamcore.dir/src/dmg/gb_apu/Gb_Apu_State.obj CMakeFiles/vbamcore.dir/src/dmg/gb_apu/Gb_Oscs.obj CMakeFiles/vbamcore.dir/src/dmg/gb_apu/Multi_Buffer.obj CMakeFiles/vbamcore.dir/src/fex_mini.obj
libvbamcore.a

 

Mine starts "/usr/bin/ar cr libvbamcore.a " ...

Which is invalid. I need a different ar.

 

Maybe you actually set the AR program to empty string somewhere (hint: line 1: "CMAKE_AR:FILEPATH=" and nothing else .. and of course my cache has "CMAKE_AR:FILEPATH=/usr/bin/ar", but I didn't "rerun [rm -rf CMakeFiles CMakeCache.txt]" cmake yet ...)?

 

Uh no, you're not cross compiling, or even reading the subject above. I'm overriding CMAKE_AR to the proper ar, and instead it's just leaving it blank, as opposed to using my changes.

Share this post


Link to post
Share on other sites

So I thought I've seen it all, now get this.

 

If I do as follows:

rm -rf CMakeCache.txt Makefile CMakeFiles

then insert INCLUDE(CMakeDetermineCCompiler) prior to ENDIF ( WINCROSS ) into CMakeLists.txt, then run

cmake -DWINCROSS=1 .

which will not produce a Makefile due to errors, then I replace INCLUDE(CMakeDetermineCCompiler) with INCLUDE(CMakeDetermineCXXCompiler) and run

cmake -DWINCROSS=1 .

make VERBOSE=1

 

Now it will find the proper ar and ranlib, but only if I do things in that order, with the first call to CMake failing. Someone want to explain this to me?

Share this post


Link to post
Share on other sites

Which is invalid. I need a different ar.

It is invalid, yes, but not for the reason you think.

It is not using "cr" for "ar".

It is using " cr" for "ar cr" [1], because your CMAKE_AR is empty, as I pointed out. Look at the first non-empty non-comment (which you posted):

CMAKE_AR:FILEPATH=

 

I don't know how that happened. Your CMakeLists.txt clearly states that CMAKE_AR should be i586-mingw32-ar.

 

[1] the "cr" just stands for "create the archive (unless it already exists) and insert named files into it (replace those that are already inside).

 

Uh no, you're not cross compiling, or even reading the subject above. I'm overriding CMAKE_AR to the proper ar, and instead it's just leaving it blank, as opposed to using my changes.

 

I don't need to cross-compile ... with empty CMAKE_AR, even straight-compiling would fail.

Of course, I can't test, because without the mingw32 suite cmake won't generate WINCROSS Makefiles for me ...


So I thought I've seen it all, now get this.

 

If I do as follows:

rm -rf CMakeCache.txt Makefile CMakeFiles

then insert INCLUDE(CMakeDetermineCCompiler) prior to ENDIF ( WINCROSS ) into CMakeLists.txt, then run

cmake -DWINCROSS=1 .

which will not produce a Makefile due to errors, then I replace INCLUDE(CMakeDetermineCCompiler) with INCLUDE(CMakeDetermineCXXCompiler) and run

cmake -DWINCROSS=1 .

make VERBOSE=1

 

Now it will find the proper ar and ranlib, but only if I do things in that order, with the first call to CMake failing. Someone want to explain this to me?

 

This one looks EASY to me.

 

CMakeDetermineCCompiler says it overrides CMAKE_C_COMPILER, CMAKE_AR, CMAKE_RANLIB, CMAKE_COMPILER_IS_GNUCC.

It *will find* your *native* gcc for C compiling. It will put this value into the cache. It will probably also find (and put into cache) your native ar and ranlib, but that isn't that bad - the archive format is (at least I think) the same. (or it will not find none and use the specified ones)

But it doesn't look for compiler of C++ so the value you specified in CMakeLists.txt is used (and put into CMakeCache.txt).

Then something will fail because cmake will be trying to compile windows binaries from C sources to make sure, OSLT, ...

 

On the second run, CMakeDetermineCXXCompiler *might* do something useful, but it will absolutely not overwrite anything that already is specified in the cache. Like the values for ar, ranlib and C compiler found previously - or the C++ compiler you specified.

Then the mingw C++ compiler is used to actually compile everything (there are no pure C sources, right?), which works.

And then it uses the ar and ranlib from previous run - which work, I assume, whether they are native or mingw32.

 

But I am no seer.

 

 

I think you should try

SET(_CMAKE_TOOLCHAIN_PREFIX i586-mingw32-)

include(CMakeDetermineCCompiler)

include(CMakeDetermineCXXCompiler)

somewhere in the WINCROSS section. It may help.

Share this post


Link to post
Share on other sites

Which is invalid. I need a different ar.

It is invalid, yes, but not for the reason you think.

It is not using "cr" for "ar".

It is using " cr" for "ar cr" [1], because your CMAKE_AR is empty, as I pointed out. Look at the first non-empty non-comment (which you posted):

CMAKE_AR:FILEPATH=

Yeah, I realized later where the cr came from, it still left me scratching my head as to why it was ignoring my ar override.

 

Uh no, you're not cross compiling, or even reading the subject above. I'm overriding CMAKE_AR to the proper ar, and instead it's just leaving it blank, as opposed to using my changes.

 

This one looks EASY to me.

 

CMakeDetermineCCompiler says it overrides CMAKE_C_COMPILER, CMAKE_AR, CMAKE_RANLIB, CMAKE_COMPILER_IS_GNUCC.

It *will find* your *native* gcc for C compiling. It will put this value into the cache. It will probably also find (and put into cache) your native ar and ranlib, but that isn't that bad - the archive format is (at least I think) the same. (or it will not find none and use the specified ones)

I'm not sure about ar, but ranlib must be the MinGW one and not the system one, because the headers are indeed different. And indeed, when run this way, it puts in my overrides.

 

But it doesn't look for compiler of C++ so the value you specified in CMakeLists.txt is used (and put into CMakeCache.txt).

Then something will fail because cmake will be trying to compile windows binaries from C sources to make sure, OSLT, ...

No, it fails because it says it doesn't have permission to write new files to /, I'm not even sure why it's trying to put anything in /.

 

And then it uses the ar and ranlib from previous run - which work, I assume, whether they are native or mingw32.

MinGW.

 

I think you should try

SET(_CMAKE_TOOLCHAIN_PREFIX i586-mingw32-)

include(CMakeDetermineCCompiler)

include(CMakeDetermineCXXCompiler)

somewhere in the WINCROSS section. It may help.

This is actually working. Thanks. I have no idea why the other overrides wouldn't work.

Now I just have to figure out how to fix the NASM problem I mentioned above, and some linking issues.

Share this post


Link to post
Share on other sites

Ok, I got it to work.

 

You have to use a recent cmake (2.6 series)

Create a new file named Toolchain-mingw32.cmake

Fill it with something like that :

# the name of the target operating system
SET(CMAKE_SYSTEM_NAME Windows)

# which compilers to use for C and C++
SET(CMAKE_C_COMPILER i586-mingw32msvc-gcc)
SET(CMAKE_CXX_COMPILER i586-mingw32msvc-g++)

# here is the target environment located
SET(CMAKE_FIND_ROOT_PATH /usr/i586-mingw32msvc /home/bbouclet/mingw )

# adjust the default behaviour of the FIND_XXX() commands:
# search headers and libraries in the target environment, search 
# programs in the host environment
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)

 

Then call cmake with :

cmake -DCMAKE_TOOLCHAIN_FILE=Toolchain-mingw32.cmake -DNO_GTK=1 .

 

It should then build without problem when using the updated CMakeLists.txt (rev 568)

Share this post


Link to post
Share on other sites

Latest SVN doesn't bother to build or link the assembly files:

CMakeFiles/vbam.dir/src/hq/asm/hq3x32.obj:hq3x32.cpp: (.text+0x244): undefined reference to `_hq3x_32'

CMakeFiles/vbam.dir/src/hq/asm/hq3x32.obj:hq3x32.cpp: (.text+0x712): undefined reference to `_hq4x_32'

CMakeFiles/vbam.dir/src/hq/asm/hq3x32.obj:hq3x32.cpp: (.text+0x93c): undefined reference to `_hq3x_32'

CMakeFiles/vbam.dir/src/hq/asm/hq3x32.obj:hq3x32.cpp: (.text+0xb5c): undefined reference to `_hq4x_32'

CMakeFiles/vbam.dir/src/hq/asm/hq3x32.obj:hq3x32.cpp: (.text+0x443): undefined reference to `_hq3x_16'

CMakeFiles/vbam.dir/src/hq/asm/hq3x32.obj:hq3x32.cpp: (.text+0x5c3): undefined reference to `_hq4x_16'

 

Is there something I should be doing to cleanup between different builds besides?:

rm -rf CMakeCache.txt Makefile CMakeFiles

 

Although bgK, it seems I can compile builds now as long as they're not using assembly :)

Share this post


Link to post
Share on other sites
Is there something I should be doing to cleanup between different builds besides?:

rm -rf CMakeCache.txt Makefile CMakeFiles

make clean

Share this post


Link to post
Share on other sites

Is there something I should be doing to cleanup between different builds besides?:

rm -rf CMakeCache.txt Makefile CMakeFiles

make clean

 

That won't do it, it only removes the object files.

Share this post


Link to post
Share on other sites

Usually I make a build folder, cd to that then do "cmake ../"

That way, I can just rm -rf build to clean up all cmake-related stuff.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×