Removed Makefiles and replaced it with CMake.

[mpapierski]

Now there is only one way to build this library. And its easier to integrate this project into other CMake projects.

Best regards!

[zorgnax]

I'm hesitant about this one since I don't know how to use cmake. Also my computer doesn't have cmake installed by default. If I ever read the cmake docs and think its actually better than make I might use this patch. I would pull it in if it didn't replace the Makefiles, but that could be kinda messy.

[beatgammit]

I'm a little in favor of this because I don't like that make install explicitly moves files to /usr/.

This project is very simple, so if you really don't want to switch to CMake, perhaps I could submit a patch to not explicitly move files to /usr.

[refi64]

If you want a makefile generator, I'd suggest Bakefile. It's based on the idea of pre-generating makefiles. The author of the project runs Bakefile and uploads the generated makefile with the project. You get lots of CMake's abilities without the giant makefiles it generates.

I also can't help but feel like this would be a HUGE dependency.

[tokenrove]

@beatgammit How about replacing /usr with $(PREFIX), which is a convention in many Makefiles? I would personally prefer to see a smaller change like that rather than breaking out CMake for a tiny project like this.

[zorgnax]

I agree with that. I didn't really think that much when I first made the install and uninstall targets.

78de74d

[mpapierski]

@kirbyfan64
The biggest strenght of CMake is not only it generates Makefiles. You can insert CMake based library inside your CMake project and the library will be part of your build system. In the end you could just link to "libtap" in your app. And dont worry about library paths.

The "big" Makefiles it generates is actually a great feature. You dont ever want to keep your generated Makefiles in your source code. CMake prefers out of source builds instead, separating code and build data. You basically create "build" directory and run cmake generator there.

I agree that switching to CMake is a big step, but most arguments about CMake are false.

Did I mention it supports more generators that just GNU Make? IDEs like VS, Eclipse, even Sublime Text are supported.

[beatgammit]

I've submitted a pull-request (#17) that makes shared objects work again (and build by default), so if that gets merged, you can just add tap as a dependency in whatever project you're using.

In any case, I still agree with moving to CMake, but I'm more interested in getting shared objects working.

[refi64]

@mpapierski I know that much; I've used CMake several times before. You also didn't explain why the big files are a feature.

The thing about Bakefile is, again, the idea of pre-generation. The user doesn't even need to know about the Makefile generator; they just run make.

Bakefile currently supports GNU make and VS. I'm looking into writing Ninja and CodeBlocks backends.

And, again, CMake is a big dependency and feels a tad overkill for a simple project. It works well for a big project like LLVM, though (although I still like Gyp better for weird configurations).