Adding premake4.lua and glue for old MSVC versions

[assarbad]

• Glue code is based on the stdint.h from Android's libusb_aah, which I
  mentioned in libtomcrypt#577, I added the stdbool.h stuff, too.
• This required adjusting the main header: tommath.h
• The premake4.lua was tested thoroughly with VS2003 through VS2008 for now

Please do not merge as of yet. I am going to refine this further. The discussion surrounding this can be found in libtomcrypt#577, as this library is a prerequisite, I am starting with this one.

[sjaeckel]

There's already a make c89 target which makes the library sources compatible 😄

I'm currently traveling, so I'll have a real look when I'm back

[assarbad]

There's already a make c89 target which makes the library sources compatible smile

I only saw your response now that I saw the comment on #526. It exists, it's a pragmatic solution, but it's not a robust solution and it only exists for developers using GNU make on a unixoid system (sed and grep dependencies).

I'm currently traveling, so I'll have a real look when I'm back

👍

[sjaeckel]

There's already a make c89 target which makes the library sources compatible smile

I only saw your response now that I saw the comment on #526. It exists, it's a pragmatic solution, but it's not a robust solution and it only exists for developers using GNU make on a unixoid system (sed and grep dependencies).

OK, that's a fair point, but TBH I'd prefer to publish another source package in c89 style when doing a release than adding yet another header file ... which is also completely MSVC specific, whereas the existing solution is a minimal set that's valid for all old compilers! (and it even builds as is on newer ones). IMO if someone really needs that, they should adapt the file as required and be happy :)

Is that acceptable for you?

Yes, developers using such old compilers and not knowing how to install make etc. won't be able to work from the Git repository but only from the tarball ... and I could live with that.

czurnieden mentioned this pull request 4 days ago
Add cmake support #528

@assarbad could cmake even be a potential replacement for all this? I doubt so, but you're the pro here.

[assarbad]

Sorry for the late response. I'll probably be a bit slow to respond in the coming days, too.

OK, that's a fair point, but TBH I'd prefer to publish another source package in c89 style when doing a release than adding yet another header file ... which is also completely MSVC specific, whereas the existing solution is a minimal set that's valid for all old compilers! (and it even builds as is on newer ones). IMO if someone really needs that, they should adapt the file as required and be happy :)

Is that acceptable for you?

Certainly.

Yes, developers using such old compilers and not knowing how to install make etc. won't be able to work from the Git repository but only from the tarball ... and I could live with that.

Yeah, it is a fair point. I'm not sure how far back one wants to take it. But I guess it would make sense to have a look whether the existing C89 compat. solution could be made to work with MSVC without the need for the above mentioned prerequisites.

@assarbad could cmake even be a potential replacement for all this? I doubt so, but you're the pro here.

It depends what the goal is. What CMake can certainly achieve is to build. It can facilitate Ninja or MSBuild for that (and some other options, depending on CMake version and build configuration). It can also generate a given VS solution/projects etc (but the CMake version has to be built for the respective target system, in this solution you could invoke Premake4 from Linux and generate VS projects without any problem, e.g. after adding source files). The big downside is that this CMake-generated project cannot be handed to anybody else. If you know autotools, you can imagine it a bit like the Makefile that autotools will eventually generate. If will offer all sorts of options, prime things for you, but if you hand the Makefile to someone else they won't necessarily be able to make use of it on their system (they could, if they ran ./configure locally to prime it to their system, though).

For CMake-generated VS projects it's even somewhat worse because it generates all sorts of pseudo-targets which hardcode (absolute) file system paths into the generated projects etc. And of course CMake will embed itself via cmake -E into the generated projects. So they aren't suitable for distribution.

So if the goal is to offer some level of VS and MSBuild support, CMake can certainly work. If the goal is to offer embedding of your lib into another CMake project: brilliant. All those fans of CMake will be very happy and it's actually a great solution for them.

But if the goal is to generate VS projects (and solutions) that a user can open and go with, then CMake isn't the appropriate tool. (And yes, it can be done such that - as an example - all the pre-generated projects and solutions live inside a subfolder instead of the root of the repo, the options are plentiful.)

So it depends on the goal. I'd love to make this work for my own benefit and that of others, but it you see it as no good fit, that's cool with me, too.