selsta ok

Has anyone tried to compiled Monero with Microsoft Visual C++ (MSVC cl.exe)? Are there any interest for doing this? Porting libraries from pacman to CMake add_subdirectory would make MSVC compilation much easier too.

MSVC was never supported, and I'm 99% sure it's not just CMake but also a lot of code that needs to be changed to be compileable with MSVC

They have pretty good C++ support now. But I am mot sure from security/privacy perspective, how reliable they are. I would put them on “reliable” category though.

Their C support sucks though.

The only thing that I miss from MSVC when working with Monero code, is their debugger tools, but it's a question of habit

I'd say if the changes are small, why not, but you have to be willing to maintain it (if it breaks soon after, why bother) and it has to be really non invasive.

The first one is, probably noone will bother going through hoops to maintain compatibility with MS, of all companies. So long term commitment to maintaining it is required.

Now, there is also the argument that making it work with Visual C means more incentive for other people to keep using windows, which is unethical in itself...

does this page have any relevant information blog.elijahlopez.ca/posts/monero-devs-windows

moneromooo: sorry for late reply, I got disconnected. The to the code would be very minimal. The bottleneck is the build. CMake does have very good support for MSVC and everything is ready from that perspective. The problem is that we do use system libraries instead of having our own `add_subdirectory` in CMake. I am even thinking about changing to our own library to git submodule and `add_subdirectory`. That would be much better

From security perspective in my opinion that is much better too. We will pull everything instead of relying on OS libraries or Pacman.

we already use depends / gitian for this

we don't rely on OS libraries for release binaries

I meant package manager libraries

each dependency is built from source, we check hashes and also can apply custom patches, otherwise reproducible builds wouldn't work

selsta: i think this is about development builds using MSVC, not release binaries

yes but xFFC suggested adding all dependencies as submodule

unless I misunderstood their suggestion from a couple days ago

submodules for all dependencies would slow down recursive checkouts by a lot

tobtoht[m]: `git clone --recurse-submodules --shallow-submodules`

tobtoht[m] selsta yes development build.

why can't MSVC use installed libraries?

why not just cross-compile with MSYS2?

The average user who custom builds monero doesn't need all dependencies built from scratch, is significantly increases build time. I also don't like adding submodules just for MSVC. Adding build support for submodule libraries for all operating system is a lot of work and basically duplicates what the depends build system does. It also means we have to maintain twice the amount of libraries, once in depends and one as submodule.

I don't have an issue with adding MSVC support if it means just small changes to CMake and no new submodules.

selsta I will take a look at the possiblity of adding MSVC support without messing too much with submodules thing.

Building without dependencies means you'll have to ship .lib files for Debug/Release builds for MSVC 2019/2022. Not an ideal solution

.lib and .pdb

of course with cmake's add_subdirectory it will all be in the same solution file and will be built locally

but build time will be long the first time

not all dependencies have a CMakeLists.txt file

I agree with the submodule thing. It's overengeneering. We lose either security (if using a fork of the upstream repo, unless someone is around to update the submodule every time something relevnat is out) or robustness (if the submodule is direct upstream master, in which case we need to fix random stuff everytime upstream makes a breaking change).

I do that in TF, but only for those repos with code I have changed. Otherwise it just adds constraints for no good reason.

If you want the ability to just run a command and get binaries, we have gitian or podman.

Not podman, I forget the name, but podman compatible.

docker!

It is also a lot slower to build. I speak from TF experience -_-

For incremental builds I mean.

<kayabanerve[m]> "1) Grab curve25519-dalek and..." <- > <@kayabanerve:matrix.org> 1) Grab curve25519-dalek and generate two scalars if you just want keys

> 2) Grab curve25519-dalek and generate one scalar, before hashing it to generate another (the view key)

> 3) Grab monero-serai and generate a seed, though our code isn't audited yet and had has to be used with consideration, before getting the key from it and then hashing that for the view key)

I was looking to just generate keys and addresses.

<WilliamMay[m]> "> <@kayabanerve:matrix.org> 1..." <- later on a full escrow service.

You could copy these lines changing the hex::decode to some sort of random bytes generator:

Then pass the keypair into this: