cmusphinx
Initial commit of experimental CMake build system
Just to save your time - I'm not sure your PR is going to be accepted. First, it's not atomic, second, your changes are questionable (like, you changed int64_t to int), last (but not least), you've been already told that CMake isn't welcome in this project. There are no problems with using an autotools-configured project in a CMake-configured project.
it's not atomic
Can you explain what you would like atomic better?
your changes are questionable (like, you changed
int64_ttoint)
It was necessary to get the code to compile on my build systems, I'm not sure how it would compile under normal circumstances otherwise.
you've been already told that CMake isn't welcome in this project
I was told that it wasn't "needed", not that it wasn't welcome. Is there a reason that CMake isn't welcome in this project? I can't foresee any downsides to adding it.
Can you explain what you would like atomic better?
Atomic changes are easier to review because there's no need to switch contexts.
It was necessary to get the code to compile on my build systems, I'm not sure how it would compile under normal circumstances otherwise.
Obviously you should fix your build system, not the project. In this particular case the change is potentially dangerous because the C standard guarantees almost nothing regarding the size of int, while the size of int64_t is always fixed.
Is there a reason that CMake isn't welcome in this project? I can't foresee any downsides to adding it.
There's already a build system, why would we need another one? If it's added, somebody will have to maintain it.
Atomic changes are easier to review because there's no need to switch contexts.
Contexts? This isn't a C concept as far as I know, can you be more explicit?
Obviously you should fix your build system, not the project.
It was failing on all of my build systems across all platforms: Windows, Mac, Linux. That indicates either something wasn't setup in the build properly (didn't seem like the case here), or the project was at fault.
C standard guarantees almost nothing regarding the size of int
The standards specify this size range:
C99 & C11 §5.2.4.2
— minimum value for an object of type int INT_MIN -32767 // −(215− 1) — maximum value for an object of type int INT_MAX +32767 // 215− 1
I agree that it may not be the safest way to handle those situations, but for now my code works on all of my build systems; yours doesn't.
There's already a build system, why would we need another one?
Actual portability. For example: building sphinxbase and pocketsphinx on Windows is a PITA right now. This is a step into making it more streamlined.
If it's added, somebody will have to maintain it.
Maintenance is minimal on build systems (that's the whole point of them). Right now all you have to do is add new files that you create so that they will be compiled... and even that could be fixed so you don't have to do that.
Anyway, I'm not the one who makes the final decision, so this was just my advice. Although I'd still wait @nshmyrev to accept your ideas before starting to write the code. FYI, building cross-platform projects on Windows has always been a pain, mainly because Visual Studio doesn't have a conforming C99 compiler and because Windows is not POSIX-compliant. I'd suggest MinGW build on UNIX-like OS instead.
Although I'd still wait nshmyrev to accept your ideas before starting to write the code
The build system is already been written, and my code that uses that build system has already been written. My fork is just serving as a "glue" between this code and mine, hopefully just temporarily.
Visual Studio doesn't have a conforming C99 compiler
Yes and no. It does support many features, but is not fully compliant.
Hi, I'm not sure who said CMake wasn't welcome, but it wasn't me. It's awful, but it's less awful than autotools, and the configuration files are quite a lot simpler.
That said I imagine lots of things have changed since 6 years ago. Please take a look at this fork which switches everything to CMake, and will change other things as well: https://github.com/dhdaines/pocketsphinx
@dhdaines nice it is going David! I suppose you can push it all to the master instead of a fork.
Hi @nshmyrev ! I was hoping to discuss some of the other changes with you which is why it's on a fork :)