6 years. What were you doing 6 years ago? In March 2004 OpenTTD 0.1 was released. Hardly a month later in April 2004 OpenTTD 0.2. And today, six years later... OpenTTD 1.0.0. It was a lot of work, hundreds of thousands of translations, tens of thousands of commits, thousands of graphics, hundreds of patches, dozen of sounds and musics, and one goal. How many people contributed? Dozen of artists, translators and developers, hundreds of testers and bug reporters, and also the thousands of players. Looking at the readmes and credit sections only gives a small hint. Some of those who were main contributors left long ago, and there are only a few who know them all and talked to them once via IRC or the forums. But if you consider all contributors, including those of the used libraries, and the external artists of OpenSFX... Well, then most likely not every contributor actually knows OpenTTD :) So in the end, what was most fun in the past 6 years of OpenTTD? Playing? Contributing? Modding? Talking? Or just taking part in a large crowed moving in one direction? One direction? Well, at least in bigger scope :) But in more detail there were quite some parties involved in the process. Sometimes pulling in the same direction, sometimes maybe pulling in slightly different ones. Let's just mention some of the projects around OpenTTD which influenced it in this or that direction: The various integrated builds and patchpacks, first of all the MiniIN. Then the first Town Growth Challenge, TTDPatch, #openttdcoop, Goal Servers and the big patches (Subsidiaries, YAPF, YAPP, CargoDist, 32bpp & ExtraZoom). And not everything which made it into main trunk was happy sunshine, just to mention the first approach to Path Based Signalling, or the attempts around the AI. But when looking back, most turned out fun. Thank you! http://www.openttd.org/en/download-stable Reproducible: Always
*** Bug 313057 has been marked as a duplicate of this bug. ***
Yes! We want this :-)
I simply renamed the 0.7.5 ebuild to 1.0.0 and it works for me on amd64.
No, we're not going to do that. 1.0 will have the open media support added.
Created attachment 226849 [details] openttd-1.0.0.ebuild =games-simulation/openttd-1.0.0.ebuild
Created attachment 226851 [details] openttd-1.0.0.ebuild =missed a few obsolete elogs, tweaked the elogs to be more relevant
(In reply to comment #5) > Created an attachment (id=226849) [details] > openttd-1.0.0.ebuild > > =games-simulation/openttd-1.0.0.ebuild > emerge: there are no ebuilds to satisfy "games-misc/opensfx". (dependency required by "games-simulation/openttd-1.0.0" [ebuild]) First u need add to portage: games-misc/opengfx games-misc/opensfx games-misc/openmsx
Created attachment 226853 [details, diff] openttd-0.7.5-to-1.0.0.ebuild.patch the same as above, in diff form
Created attachment 226855 [details] metadata.xml.patch metadata.xml updates wrt new USE flag
Just relalized I left the maintainer line in metadata.xml when porting it from gamerlay. It can either be taken out, or considered as an offer to proxy maintain openttd + deps
(In reply to comment #7) > (In reply to comment #5) > > Created an attachment (id=226849) [details] [details] > > openttd-1.0.0.ebuild > > > > =games-simulation/openttd-1.0.0.ebuild > > > > emerge: there are no ebuilds to satisfy "games-misc/opensfx". > (dependency required by "games-simulation/openttd-1.0.0" [ebuild]) > > First u need add to portage: > games-misc/opengfx > games-misc/opensfx > games-misc/openmsx > Yes, see bugs 300328, 308355, exist for opengfx, opensfx, and their respective build dependencies which are not in tree. No bug exists for openmsx, so I will attach it to this bug
Created attachment 226857 [details] openmsx-0.2.1.ebuild games-misc/openmsx-0.2.1.ebuild
Created attachment 226889 [details] openmsx-0.2.1.ebuild games-misc/openmsx-0.2.1 inherit python, set active version of python to 2, clean up quoting
Thanks a lot! Works great for me on ~amd64
Created attachment 227765 [details, diff] openttd-1.0.0-build.patch
Comment on attachment 227765 [details, diff] openttd-1.0.0-build.patch Separate CFLAGS and CXXFLAGS, don't pass CFLAGS to CXX, and make sure that CXXFLAGS and CFLAGS both contain enough info to compile
Upon discussion with upstream, I am chagrined to discover that the build patch may be unecessary. If it is not a bad thing, CFLAGS may be overridden with CXXFLAGS, or CFLAGS passed as a blank string to the configure script. Openttd is compiled entirely with the C++ compiler. Upstream incorporates CFLAGS because that is the workflow of their developers: to pass options with CFLAGS. I have tested the ebuild with the configure line starting as: CFLAGS="" ./configure I also tested with CFLAGS=${CXXFLAGS} though that results in the contents of CXXFLAGS being passed twice. Overriding CFLAGS with an empty string does prevent passing the contents of a user's CFLAGS (provided they don't simply CXXFLAGS=${CFLAGS} in /etc/make.conf), but I am unsure if it is The Right Thing to do.
Created attachment 227951 [details] openttd-1.0.0.ebuild The alternative to the build.patch. CFLAGS= ./configure
Created attachment 227953 [details] openttd-1.0.0.ebuild The alternative to the build.patch. CFLAGS="" ./configure
in portage. thanks for the bug report and ebuild.
