• All, I am currently in the process of migrating domain registrations. During this time there may be some intermittent outages or slowdowns. Please contact staff if you have any questions.

Build number in Openbor

haxpor if there is not problems and this is merged then you will have to first update "engine/source/build_number.h" both #defines need to match the build number one is a number the other is a string.  Next build the android build.bat then the main build.bat with option "all" this will make a zip file that includes all the releases.
 
Yeah... I'm not about to approve this without looking deeper first, sorry friend. It seems you just made it even more complex than before. Take a look at what Plombo said. He's far more versed in git source control than either of us.

DC
 
Plombo can you clarify your method.  Are you suggesting we run version.sh before every commit so openbor records your local branch commit count before you commit ? If not please give a more detailed explanation please.
 
msmalik681 said:
Plombo can you clarify your method.  Are you suggesting we run version.sh before every commit so openbor records your local branch commit count before you commit ? If not please give a more detailed explanation please.

What I'm saying is that over a decade ago, SX (at least I think it was him) implemented a system to include the engine "build number" in OpenBOR. We still have that system. It still works. I can compile OpenBOR today, and run the engine, and on the startup menu and in the logs, it will show the correct build number.

Why are we talking about reinventing it? What about the existing system doesn't work? No one has answered this for me yet.
 
The only thing I added was building the .res file within the build but I have taken on board what you have said and I will update to use github method you mentioned instead.
 
Plombo said:
msmalik681 said:
Plombo can you clarify your method.  Are you suggesting we run version.sh before every commit so openbor records your local branch commit count before you commit ? If not please give a more detailed explanation please.

What I'm saying is that over a decade ago, SX (at least I think it was him) implemented a system to include the engine "build number" in OpenBOR. We still have that system. It still works. I can compile OpenBOR today, and run the engine, and on the startup menu and in the logs, it will show the correct build number.

Why are we talking about reinventing it? What about the existing system doesn't work? No one has answered this for me yet.

Plombo that stopped to work like many, many builds ago - I think it was even before the build 4XXX era.

haxpor  had sent a commit with this, even with commit track too, take a look https://github.com/DCurrent/openbor/pull/149
 
O Ilusionista said:
Plombo that stopped to work like many, many builds ago - I think it was even before the build 4XXX era.

haxpor  had sent a commit with this, even with commit track too, take a look https://github.com/DCurrent/openbor/pull/149

The system has worked for me all this time, so it's not broken. It's just a matter of configuration.

The haxpor PR you linked doesn't do what you seem to think it does. It doesn't change the system for getting build numbers. It just adds to it with a git commit hash, which it obtains in a similar way to how we get the build number. If anything, it's proof that the existing system works.
 
"The system has worked for me all this time, so it's not broken. It's just a matter of configuration."
Plombo please read again. I haven't said its broken, I said it was not working - for some years.
Or we would having this discussion.

I really like the haxpor version because of the hash commit. This would help us to identify commits that can brake things.
 
Plombo  it has not been working for a long time and it has caused issues tracking what build broke what mod.  As long as it works in windows I am happy with the haxpor update.
 
msmalik681 said:
Plombo  it has not been working for a long time and it has caused issues tracking what build broke what mod.  As long as it works in windows I am happy with the haxpor update.

Haxpor's change looks good to me, too, but I don't know why we're talking about it here. It doesn't actually change how build numbers work. Just like the existing system works for me, it appears to work for haxpor, too. Unless I'm seriously missing something in the code, that PR won't change whether or not build numbers work for you. (That's not a problem with it; it's not meant to do that.) It'll continue to work for those of us for whom it already works, and continue to not work for you and O Ilusionista.

Instead of going back and forth about whether the existing system works, now that we know it works for only some of us, what we should be doing is asking why that is. Clearly something is different between our configurations. My hypothesis is that you two don't have the command line git executable in your PATH, and that's the difference.
 
I see so you have git in your environment variables that makes sense so really no update was required everything was working we just did not have the right setup. So does this SVN zip file in tools have something that can run git commands ? (the svn file never used to extract during setup but haxpor's version does)
 
The SVN zip file in tools doesn't have git in it. It's an artifact of SVN, the version control system we used before Git. But back in the SVN days, it solved basically the same problem that we have now -- it meant you could get build numbers without the SVN executable being in your PATH. So we could take some inspiration from that, and try putting a version of git in tools, so that you wouldn't need the git executable in your PATH.
 
It looks like the Git for Windows releases include a minimalist Git distribution called MinGit that we could probably use.
 
Oh, but if we're adding more software to the tools directory, we'll run into the same issues I brought up in this thread. Fortunately, we can use the same solution I suggested there! Git for Windows is already distributed using a GitHub releases page, so we wouldn't even have to mirror it ourselves, just make a shell script to download it from there.

If you're okay with that solution but don't want to mess with writing the script to download it, I can do it. Just let me know one way or the other.
 
That is exactly what I have looked into mingit cut down to the bare minimum is about 5mb compressed and if we get rid of svn tools we save 3.7mb that should keep things around the same size for now.
 
Back
Top Bottom