How the heck build this library?

[ghost]

I've been trying to put together this damn library all day for VS2019 Windows.
Could you make building the library a little more difficult?
If this is an open source library, why do you need to build it at all?
PS:Boost is an true open source library and you don't need to build anything there - just include the header files that represent the open source implementation.

[raysan5]

https://github.com/raysan5/raylib/tree/master/projects/VS2019

[orcmid]

@Latorius There are good reasons for compiling library .obj files from source, including getting the compilation options to line up (as well as x64 versus x86 versus ...).

I think there is confusion about the general notion of a library and an API for it as opposed to a "shared library" or a "linker library" or a DLL. Ray gets to choose. We can always contribute something we find missing.

With regard to all the VS library dependencies, there might be some help in getting the *.obj files that you need to pass into the lib utility by digging into raylib/projects/scripts and seeing how the build_windows.bat script populates a temp cache of the .obj files that can be incorporated in a static *.lib. There are some dependencies on other libs and that shows up in the final cl.exe operation. I'm not certain how those get reflected in building the *.lib you want. And if you want a DLL, I offer no clue about that.

I also notice (but have not tested) that you can do something similar with VS 2022 by working in a folder directly and not going the project/solution route. And of course you can create a Visual Studio project to do the job. Then you can have debug and release builds, etc.

My experience so far is that the 'build_windows.bat` scheme works just fine to have a compiled cache and a linking pass at the end of compiling your own source. I like that so much I have made my own derivative as part of encouraging beginners to make raylib projects of their own. It will look unfamiliar. It is a very compact way to work on making raylib apps. (There is no debug option though, and link-time code generation is used all the time.)

[orcmid]

@Latorius There are good reasons for compiling library .obj files from source, including getting the compilation options to line up (as well as x64 versus x86 versus ...).
...
With regard to all the VS library dependencies, there might be some help in getting the *.obj files that you need to pass into the lib utility by digging into raylib/projects/scripts

My experience so far is that the 'build_windows.bat` scheme works just fine to have a compiled cache and a linking pass at the end of compiling your own source. I like that so much I have made [my own derivative]

A good place to see a refactoring of build_wndows.bat and understand how the VS Build Tools (namely CL.exe) are used is to look in the folder https://github.com/orcmid/nfoTools/tree/master/devKits/WinDev/VCrayApp/dev/cache
and read the cache.txt file and look at the various *.opt files for details of what to compile to make a cache (instead of a .lib) and then linking from it with a compiled source and some externally-needed libraries. You could instead use the VS lib.exe utility to make a static library of the compiled raylib *.obj files and then use that in projects. It would still have to be in the configuration and you'd have to keep the raylib.lib somewhere.

Looking at it this way, I don't see much difference between caching and reusing the raylib *.obj and building a raylib.lib file that is essentially a packaging of those same *.obj. It might make some difference for integrating into VS 2019/2022 projects and solutions, or even VS Code projects, I don't think it has to. It takes some expertise in how those IDEs can be used to embrace raylib-using projects.

One thing I have neglected is having debug vs. release builds. build_windows.bat does support that distinction and includes a debug build option. My neglect of that is intentional.

[ghost]

if raylib is - source code files, then by uploading them, for example, to VS2019 - they will have to compile, right?
I don't really like building libraries, because if the project is open source, I like to load it completely in IDE and work with it as open source, not as a include lib file.
But with me with raylib it doesn't work out that way.

[orcmid]

@Latorius .... if the project is open source, I like to load it completely in IDE and work with it as open source, not as a include lib file. But with me with raylib it doesn't work out that way.

That is what I do. I install raylib from a release .zip just for stability in my raylib-based projects. That is rather than forking and cloning it (which I also do when monkeying with raylib itself). Either way, it is all source code and the only reason for precompiling the 8 standard raylib *.obj files is to save on recompiling and linking time when working on my own source code.

Is that what you (@Latorius) have in mind?

In Visual Studio, I think a Make setup could accomplish the same thing. The script I adapted is for command-line builds under a command prompt like the "x64 Native Tools Command Prompt for VS 2022" (or 2019). My rayApp.bat script presumes that the raylib/ source-code folder is always a fixed relative distance from any of my raylib-dependent projects. In Visual Studio, you can just say where it is and also specify the include paths for raylib header files. VS Code is a bit trickier.