Membership #6260

Applying for project: HardPack

Added by Vaulter over 6 years ago. Updated almost 4 years ago.

Status:ClosedStart date:2013-08-09
Priority:LowDue date:
Assignee:Vaulter% Done:

100%

Category:Compile Farm
Target version:-

Description

Hello, I would like to request a project on your DevZone, my work is or will be GPL and therefore legitimate to be hosted from you.
It all about HardPack patchpack. Wanna build it under Win32 easily and comfortable way :)

vs_hard_pack.0.8.155.r25702M.patch.7z (341 KB) Vaulter, 2013-08-09 17:51

History

#1 Updated by planetmaker over 6 years ago

  • Status changed from New to Feedback
  • % Done changed from 0 to 10

That could work, but setting up such compile job is not a one-click thing:
Which version control system do you use? It is absolutely mandatory to use one. Mercurial is easier (also in setting up), but if you already use git, it would be a pain to convert and I'd need to setup that manually. That repository needs to be a complete OpenTTD repository with the patches applied to the source code, not just the patches themselves.

For projects like ChillPP, CargoDist or InfraSharing we asked TrueBrain to kindly create a build job on OpenTTD's own compile farm. That build job pulls the complete source from the DevZone repository, and pushes back the binaries to #openttdcoop's bundle server. It's something which one only will be able to do when the previous question is answered and the repository exists already with meaningful source.

#2 Updated by Vaulter over 6 years ago

i use mostly SVN. Ok, can i create repo at DevZone by myself?

#3 Updated by planetmaker over 6 years ago

Due to the centralized nature of subversion I'd like to recommend NOT using subversion. Mercurial and git as distributed VCS have the advantage that everyone has the complete history with a clone; they both also have better support for patch queues than subversion.

The default repository-type on the DevZone is mercurial, these can be created by users, if they are already manager of another project at the DevZone. Other repository types need manual creation.

For now I created the project with a mercurial repository at http://dev.openttdcoop.org/projects/hardpack
http://dev.openttdcoop.org/projects/home/wiki/Mercurial explains on how it can be accessed. Mercurial for svn users is explained here: http://hgbook.red-bean.com/read/migrating-to-mercurial.html#id442397 and more general http://mercurial.selenic.com/wiki/BeginnersGuides

#4 Updated by planetmaker about 6 years ago

I forgot to mention... here it is: http://dev.openttdcoop.org/projects/hardpack

#5 Updated by Vaulter about 6 years ago

Ok, i put patched source
right now it's just patched sources, but i'm wondering how to make subrepo with opentdd trunk with hg queue of patches and put it all to this repo and make it work, anyway
we ready to go further

#6 Updated by planetmaker about 6 years ago

Probably the easiest way is to not use a patch queue but commit that to this mercurial repository as "real" commits upon the openttd trunk code:
- clone OpenTTD trunk
- apply the patches in single commits one after one
- tag a commit when you think that the version as-is with all those patches works and should be compiled

When you want to update to a newer OpenTTD version procedure you have several ways to proceed:
a) use graft
- pull all new OpenTTD changes: hg pull
- update to the revision you want your patches based upon then: hg up rXX
graft the changesets (patches) to the new revision one by one: hg graft XX (where XX is the changeset the patch has in the previous release)

b) use merges
- pull all new OpenTTD changes and update to it: hg pull u
merge the patches into the updated trunk: hg merge

c) use the mutuable history plug-in (which is supposed to be an alternative to using mq)
see http://hg-lab.logilab.org/doc/mutable-history/html/

In any case, building works much better from a repository which can just be cloned / pulled without resorting the mercurial queues. We use hg 2.6 on our server, thus we could also configure your repo to be "non-publishing" which means that you can push draft changesets and later rebase them to a newer OpenTTD version using this extension. It also makes then sense to use hg commit --amend and hg evolve a lot. To me that's a nice workflow when working on patch queues :-)

#7 Updated by Vaulter about 6 years ago

ok, so will continue submiting complete sources ready to built
how to get win32/64 bundles then?

#8 Updated by planetmaker over 5 years ago

Ok, it's a long time that anything happend on this. Is there still interest in using the compile service?

http://farm.openttd.org/browse/OTTD3PT-CHILL-PUB-24 is the result of the compilation, it failed for windows and OSX. But OpenTTD's CF only publishes if all targets build successfully, thus the resulting binaries are nowhere available. They would be available at http://bundles.openttdcoop.org/hardpack, if it succeeds.

OpenTTD's CF is now setup to build nightlies of this PP at around 4am (CET iirc).

#9 Updated by planetmaker over 5 years ago

  • % Done changed from 10 to 100
  • Assignee set to Vaulter

#10 Updated by frosch almost 4 years ago

  • Status changed from Feedback to Closed

Also available in: Atom PDF