How can i build the library on the windows platform?

[tomcatter]

Hi, friend, I need to compile this library on the windows platform. What changes do i need to use vs? Do you have a manual to use? thanks!

[BurningEnlightenment]

Hi; the library will compile just fine if you provide the configuration options (which codecs to include) via command line or a hardcoded config.h. So you just need to create a build definition or use the cmake build scripts I created, see #7 and/or BurningEnlightenment/base64-cmake
EDIT: my build scripts haven't been updated to include the last two commits due to lack of time; if you invest time into updating my build scripts, I would happily accept a PR 😉

[tomcatter]

@BurningEnlightenment Thanks! I'm not familiar with scripting camke yet. But I'll try to rewrite it when i have time. (By the way, what's the meaning of this PR? I'm a freshman in English.)

[BurningEnlightenment]

PR=Pull Request

[tomcatter]

@BurningEnlightenment Thanks again!

[BurningEnlightenment]

@aklomp @tomcatter may consider closing this issue?

[emmenlau]

Hi, I just found your library and want to say "two thumbs up for the great work!".

But can I also kindly ask if the cmake-based build instructions could be included in the official release? It seems the cmake-fork is current up-to-date, but since base64 can be used in security-related applications I'd very much like to be on the official repo and not on a fork. It's really just a humble request, please do not feel pushed into something. But the cmake build is really nice due to cross platform support and the install target.

[aklomp]

Hey, thanks for the compliment. Allow me to explain why I've been reluctant to merge the cmake fork. The situation is a bit nuanced, as I hope will become clear.

On the surface, the issue seems straightforward. Support for cmake is probably the most requested feature for this library. The code in question has already been written and is being maintained externally. The person who wrote it (@BurningEnlightenment) did a good job and spent quite some effort on it, even rewriting it once. The code could be merged right now without much of a problem. Then why not merge it?

The thing is that I don't know cmake. Adding cmake support means that it will be there permanently as a core feature. It would forever place on me the burden of maintaining a piece of code in the heart of the project that I do not understand and cannot reason much about. I fear that this could become a liability to the project if I'm not familiar enough with cmake to update (or modernize) it as time changes. It would risk turning into a poorly understood layer of arcane magic spells. It would feel like part of the project slipped out beyond my control.

The way out of this is clear: I should just get on with it and learn cmake. Which is what I said I'd do a long time ago 😿

In the meantime I think it wouldn't be too unreasonable to just use the cmake fork if it works for you. This library is fairly stable, it's not something I spend much time or thought on anymore, so you don't have to be too afraid of diverging branches. And if the branches do diverge, it's probably because the official project got cmake support 😸

[aklomp]

CMake support was recently merged into master (see #7), so this library now supports compilation on Windows.