search

berkeleydb / libdb

Berkeley DB
http://libdb.org/
327 stars 76 forks source link

5.3.28 tag problem (same than 5.3.21) #8

Open Neustradamus opened 1 year ago

Neustradamus commented 1 year ago

@gburd: There is a tag problem for 5.3.28:

Currently :

Can you add the 5.3.28 code to do not have only 5.3.21.

Can you add the last code in master and create the good tag?

Thanks in advance.

greenkalx commented 1 year ago

My vote for this as well. These folders are missing from the repo: build_android, build_vxworks, build_wince, build_windows But they are available in the 5.3.28 release: https://github.com/berkeleydb/libdb/releases/download/v5.3.28/db-5.3.28.tar.gz

I am compiling with Visual Studio 2022, there are some name collisions with Windows atomic: C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.34.31933\include\atomic I can provide a patch to rename some macros to avoid this. Note these compile issues are not present for Visual Studio 2017.

Regards

gburd commented 1 year ago

Pull requests are welcome On Dec 14, 2022, at 4:25 PM, greenkalx @.***> wrote: My vote for this as well. These folders are missing from the repo: build_android, build_vxworks, build_wince, build_windows But they are available in the 5.3.28 release: https://github.com/berkeleydb/libdb/releases/download/v5.3.28/db-5.3.28.tar.gz I am compiling with Visual Studio 2022, there are some name collisions with Windows atomic: C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.34.31933\include\atomic I can provide a patch to rename some macros to avoid this. Note these compile issues are not present for Visual Studio 2017. Regards

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

greenkalx commented 1 year ago

I think we need to have 5.3.28 first, because my VS2022 patch modifies db.h in build_windows, and seven more files. Want a 5.3.28 pull request first?

greenkalx commented 1 year ago

I tried merging all the files from the release tarball, but it's 9000+ files and my git Fork app is spinning all night when I push. I would try again, breaking it into two, one commit with just 'doc' folder of ~5000 files.

Is it enough to create a local branch and push for the branch to be created on github? Or I need to fork the repo? I'm coming from a dev environment where we create a remote branch from Jira. Then push to that branch and make a PR.

greenkalx commented 1 year ago

I also wasn't sure about the license and which files it covers for this repo. In the tarball, there is a LICENSE file with an Oracle and NASM license. In this repo, there is a LEGAL file with a Sleepycat license.

Neustradamus commented 1 year ago

There is a problem of tag (5.3.21 = 5.3.28) here and the last official build with Sleepycat license is 6.0.19:

greenkalx commented 1 year ago

The patch I'm using to compile with VS2022: 0006-vs2022_avoid_name_collisions.patch This applies on the 5.3.28 release, not the repo which needs updating from 5.3.21 as I wrote above.