search

gavinhoward / bc

An implementation of the POSIX bc calculator with GNU extensions and dc, moved away from GitHub. Finished, but well-maintained.
https://git.gavinhoward.com/gavin/bc
Other
145 stars 29 forks source link

CMake support #68

Open SamuelMarks opened 11 months ago

SamuelMarks commented 11 months ago

WiP

Can finish if you like. Can also send you a PR on your own website, just make me an account

gavinhoward commented 11 months ago

Thank you for the PR!

Allow me to I apologize upfront. Usually, I do not question user requests; after all, there is a user, and they have a request, so obviously, there is a need or a want.

However, personally, I hate CMake. I hate it so much that I have spent three years designing and implementing a build system to remove it from my other project, a build system that would allow building on Windows, Mac OSX, Linux, the BSD's, etc. And I was going to add support for that build system to bc, which I hoped would remove any need for people to use CMake to build bc cross-platform.

So, I apologize because I can tell you put a lot of work into this, but for once, I am asking you to provide justification. I won't ask for much; I just need to know why CMake is necessary and why you believe that keeping a fork would not serve. (Since a separate build system won't touch the code, it seems like an easy fork to keep.)

Again, I'm sorry.

Also, if I do decide to merge, I'm going to need you to explain the more complicated bits; I've tried to avoid complicated CMake as much as possible. But I need to be able to maintain the CMake code without your help.

SamuelMarks commented 11 months ago

@gavinhoward I'm obsessed with interoperability. CMake is one way to achieve this. Open to your build system also, where I plan on taking bc to:

…and yes I know you support some of these targets already.

There are some other nice advantages like CPack and CTest, but honestly there are a number of other nice build generators out there and I tend to choose CMake just because it's the most popular and has a good number of generators.

gavinhoward commented 11 months ago

Okay, interoperability is something I can understand. But oh boy, I would love it if my build system could do all that.

That said, my build system (named Rig, by the way) won't be able to cross-compile in the first release, so some of those targets may not be possible in the first release of Rig. (OpenWatcom is the one that makes me most nervous.)

So I'll make you a deal. I'll do these things:

  1. Merge your PR,
  2. Set up Rig in my bc once it's ready,
  3. Write you a tutorial on how to use Rig for bc, and
  4. Help you understand the new build scripts,

as long as you'll do the following:

  1. Give me your contact info because this is a pretty big commitment, and I want to be able to ask you questions, if at all possible (you can use the info at https://gavinhoward.com/contact/ to send me that info privately),
  2. Point me to material that will help me set up environments for all of those platforms (so I can test bc and CMake on them myself),
  3. Explain to me any CMake code I don't understand (I'll make them reviews in the PR),
  4. Learn how to use Rig for bc once it's ready (I don't care if you use it for anything else), and
  5. At that point, give me your honest opinion if Rig can fully replace the CMake build.

If it can, I'd really like to remove the CMake then. If it can't, well, it can't, and CMake will stay in perpetuity.

In other words, I'll add CMake now if you'll give Rig a fair shake later.

Oh, and point number 2 is crucial; if I can't test bc on those platforms with CMake, I won't merge the PR because I would basically be committing to supporting those platforms by merging the PR, and I can't do that without the ability to test.

By the way, I only need to know how to set up environments for:

I have the capability for the rest.

SamuelMarks commented 11 months ago

Great yeah sure I'll give it a shot. No guaranteed time commitments (because of everything going on in my life); but I'll see what I can do.

My email is samuel`at symbol offscale.io; or you can use myfirstname mylastname `at symbol gmail.com.

I wrote some Windows Batch scripts for building on these different targets, and lots of things can run in a good CI/CD environment (e.g., GitHub Actions, Cirrus CI, &etc.): https://github.com/offscale/win-cmake-multi-build

Obviously still a ways to go to support all the different targets I'm interested in. But yeah something clean like your bc might be just complicated enough to test out my interoperability

gavinhoward commented 11 months ago

Okay. Thank you.

Please let me know when this PR is not WIP.

SamuelMarks commented 11 months ago

Sure thing, I'll see if I can get to it later in the week. Last remaining errors:

bc.c.obj : error LNK2001: unresolved external symbol _bc_help
vm.c.obj : error LNK2001: unresolved external symbol _bc_lib
vm.c.obj : error LNK2001: unresolved external symbol _bc_lib_name
vm.c.obj : error LNK2001: unresolved external symbol _bc_lib2
vm.c.obj : error LNK2001: unresolved external symbol _bc_lib2_name

Which should be defined in an object file that you define in your existent configure script:

contents=$(replace "$contents" "BC_HELP_O" "$bc_help")

So I just need to reverse-engineer it into CMake and we should be good to go™.