Jump to content

s0600204

WFG Programming Team
  • Posts

    263
  • Joined

  • Last visited

  • Days Won

    6

Posts posted by s0600204

  1. Firstly, thanks for working on this.

    If we're excluding Windows-only binary files from the gitea repo, would the contents of ./build/bin be considered candidates for removal? And ./build/premake/premake5/bin/release/premake.exe?

    • For Linux and macOS, the premake binary is (re)built as part of update-workspaces.sh, and I don't immediately see why we couldn't (eventually) do the same on Windows;
    • The cxxtestgen executable only seems to exist to get around the need to install python, (which we require on *nix to also build spidermonkey - for Windows, python is bundled inside mozbuild, a required prerequisite on Windows-systems only);
    • The svnversion executable
      • looks to only be used during the creation of a release (and so would only need to be installed on whatever machine was assembling a Windows release), and
      • likely wouldn't work if we start cutting releases from gitea anyhow.
    • Like 1
  2. 3 hours ago, hyperion said:

    I tried fixing sm91 for python 3.12, that one looks really tricky, needs more than linked patch  in the bug and I ended up with binary patches for virtualenv before stopping for now. If we can't add git to the build deps I fear we won't add support for python 3.12 either.

    Incidentally, I've also tried looking into this. I'm pleased to say that (after spending more time than I care to admit on it) I can now successfully build sm91 using python 3.12. The bad news that is that my solution as-is is a mess, and probably won't work for others, particularly Windows or macOS users.

    It would be a lot easier, I'd imagine/hope, to patch SM102.

    • Like 1
  3. What you're looking for is the Builder component (<Builder></Builder>).

    Notably, the following mixin file, which is included into the definition of every unit that can build buildings: https://code.wildfiregames.com/source/0ad/browse/ps/trunk/binaries/data/mods/public/simulation/templates/mixins/builder.xml

    Note that this does provide civ-specificity: if your new structure template is named, say, brit/camp_example.xml, then adding it to the above file as structures/{civ}/camp_example will cause it to only appear in the build list of Britannic builders (builder units belonging to other civs - e.g. in-game allies - will be able to assist with construction once the foundation has been laid). The absence of, say, a mace/camp_example.xml template is silently ignored.

    That said, Athenian builders have an additional mixin for Athenian-only buildings: https://code.wildfiregames.com/source/0ad/browse/ps/trunk/binaries/data/mods/public/simulation/templates/mixins/civ/athen.xml

    You can also add it to specific unit templates, like how the Roman Army Camp is listed at the top of the "Basic"-rank variant of the Roman units that can build it: https://code.wildfiregames.com/source/0ad/browse/ps/trunk/binaries/data/mods/public/simulation/templates/units/rome/infantry_swordsman_b.xml

     

  4. spidermonkey, when built as part of the pyrogenesis pre-build process, explicitly and intentionally disables the Intl api due to problems with the spidemonkey build process erroneously inserting an otherwise non-compatible version of the ICU headers into the include search paths of pyrogenesis, causing build failures. (See #5868)

    Subsequently, anything that uses the Intl api (e.g. <Date Instance>.toLocaleTimeString()) may not work as expected and (it seems) will fallback on using the local timezone of the computer upon which it is run. As 0 A.D. does not itself make use of this API, this has not been a problem until now.

    This is why you've had to use manual timezone offsets - the values of which will most likely only be correct for you and anyone else in your timezone, and only as long as you and your targets don't transition in or out of daylight saving time - instead of being able to leave timezone calculations to .toLocalTimeString(); and also why timezone identifiers are ignored and not validated.

    If/when D3127 is merged, it might be possible to re-enable the Intl api - people using a system-repo provided version of spidermonkey will most likely have access to it - but that will need testing and will not happen with the next release.


    Alternatively, it might be possible to consider building spidermonkey with the --with-system-icu flag instead of the --without-intl-api flag - which also prevents the issue with incorrect ICU headers - although some research may be needed to work out why the latter was used in preference to the former in the first place. (Added as part of the upgrade from SM24 to SM31 in r16214. In SM24 the Intl api was disabled by default; in SM31 it was enabled by default. As we don't use the api, perhaps it was to get a quicker build?)

  5. 8 minutes ago, Vantha said:

    Is  it the usual template_unit_ship_warship_light in the templates folder that other ships use?

    Yes.

     

    Quote

    Then what does the "civ/athen|" mean?

    It's what's described as a "mixin", and it is used to add attributes common to many Athenian templates in a bid to reduce duplication. The template it refers to can be located in simulation/templates/mixins.

    • Like 1
    • Thanks 1
  6. 23 hours ago, wowgetoffyourcellphone said:

    Running it in A27 it throws no errors, but there are some obvious bugs; also bugs the game (with no error codes). Interesting to look at though and think about how it could be.

    Unsurprising. I'm a little busy at the moment with work, but I'll look into it when I get time.

     

    @ShadowOfHassen, hyperion's suggestion of working on top of a fork of 0ad.git is what I do for my two mods listed on mod.io.

    The script he provided (which works roughly the same as the script I wrote and use for the same task on my computer) detects which files have been altered, which means the output mod file will only contain files that have been modified by your commits.

    The script also supports auto-marking files that should be "deleted" (read: ignored) from mods that appear above it in the in-game mod list. As what you're attempting to do is modify not remove templates, this feature is probably not one you'll be using.

    • Like 2
  7. Unfortunately SETUPTOOLS_USE_DISTUTILS=stdlib is not a long-term solution, as the python standard lib's distutils is deprecated as of python 3.10 and due to be removed as part of python 3.12 (scheduled to be released October 2023). If spidermonkey intends to keep using distutils past that point, they are going to have to use setuptools' vendored version. (And either spidermonkey, Debian, setuptools - or a combination of all three - are going to have to come up with an official solution to this.)

    @Itms with the caveat that as of writing this I haven't completed a full build of spidermonkey on my VM - so there may be failure later in the build - here's the patch:FixInstallScheme.diff Needless to say it's not suitable for applying on Windows systems (as that would, at a guess, use the "nt" scheme).

    • Like 2
  8. Ok, I've now created a Bookworm VM myself, and my current findings:

    1. I can duplicate the build failure if python3-setuptools is installed from the Debian repos. Uninstalling it clears the issue. (@hyperion this is probably what you're missing.)
    2. My earlier patch doesn't work.
    3. The reason it doesn't work is because of how setuptools resolves the installation scheme - ask it to use "posix_prefix", and setuptools asks sysconfig what the preferred scheme is for "prefix", whereupon it gets the response "posix_local". So setuptools uses that scheme instead.
    4. That reason sysconfig returns that value is due to the modifications Debian has made to that module. (It's also where the detection of virtual environments takes place. And fails because this bit of the process isn't being run inside a virtualenv.)
    5. setuptools attempts to use "posix_prefix" on posix-y systems anyway under certain circumstances (which spidermonkey's build process meets), so my patch - even if it was correct - is redundant.

    @Itms I may have an alternate solution - albeit one that will conflict with the patch you've imported from SM - but I need to sleep right now so I shall have to get back to you with it.

    • Like 1
  9. Heh, looks like @Itms was a few of hours ahead of me in investigating!

    Quote

    17:07 <@Itms> I'm really not sure what Debian is doing that fumbles the output of distutils

    At a guess, this: https://salsa.debian.org/cpython-team/python3/-/blob/python3.10/debian/patches/distutils-install-layout.diff

    (There is also https://salsa.debian.org/cpython-team/python3/-/blob/python3.10/debian/patches/sysconfig-debian-schemes.diff which modifies sysconfig, which appears to be where DEB_PYTHON_INSTALL_LAYOUT is read.)

    It adds two new "Install Schemes": unix_local and deb_system.

    The default "Install Scheme" for Debian(-derived) distros is unix_local; which has the "purelib" path template of '{base}/local/lib/python{py_version_short}/dist-packages' which matches @zyli's initial report above.

    With the DEB_PYTHON_INSTALL_LAYOUT environment variable set to "deb", the "Install Scheme" used changes to deb_system; which has the "purelib" path template of '{base}/lib/python3/dist-packages', which matches the last reported attempt.

    Both patches have code that detects virtual environments (and uses the posix_prefix install scheme instead in that case) - however this detection only functions when it is run inside a virtual environment, and this point of the spidermonkey build process is run outside it.

    That said, I may have a solution:installscheme.patch


    @hyperion Out of curiosity, are setuptools/virtualenv/distutils installed globally in that image? (Or need installing globally as part of the process?)

     

  10. Something has changed: the path given by the "FileNotFound" error message earlier:

    '/home/domowy/svn/0ad/libraries/source/spidermonkey/mozjs-91.13.1/build-debug/_virtualenvs/common/local/lib/python3.10/dist-packages'

    has now lost its "local" subpath

    '/home/domowy/svn/0ad/libraries/source/spidermonkey/mozjs-91.13.1/build-debug/_virtualenvs/common/lib/python3/dist-packages'

    One step forward!

     

    @zyli, would I be right in thinking that if you go to

    /home/domowy/svn/0ad/libraries/source/spidermonkey/mozjs-91.13.1/build-debug/_virtualenvs/common/lib/python3

     there is a "site-packages" subdirectory but not "dist-packages"?

  11. On 05/01/2023 at 7:09 PM, RangerK said:

    2) When watching a multiplayer replay, when you click on a player's civilization emblem, it opens the structure tree of the previously opened civilization. 

    Intentional (by design of the session UI, not the Structure Tree), and dates back to this Revision.

    Easily changed by altering this line of code.

    Note the same thing occurs in the game setup screen (also by design, and also that Revision, but behaviour defined in a different file).

    • Like 2
  12. My thoughts:

    • I like git;
    • (Bit controversial, but) I also like Phabricator (and, despite its flaws, arcanist!)
      • (So I'd like to see consideration of migrating across to Phorge - once the Phorge team release a guide as to how to do that!)
    • I'd like to see the repository split to differentiate between the engine and the game;
    • I'd like to see binaries off-loaded via git-lfs or some other suitable tool;
    • I'd like to for us to stop committing Windows-only binaries into the repository, but make them available through other means for those unable (or unwilling) to build themselves:
      • The same process could potentially be used to provide "nightly" builds for macOS and some Linux distros as well;
      • (On a related note, I'd also like to see a build script for Windows like the one we have for macOS - e.g. it also fetches and builds the libraries/dependencies. But that's for another thread.)
    • We should continue to be self-hosted where possible;
    • Like 2
    • Thanks 1
  13. On 17/12/2021 at 8:40 PM, bb_ said:
    On 08/12/2021 at 11:05 AM, Stan` said:

    Do note however that they are considering dropping subversion as mentioned by @s0600204 here.

     

    In the initial flurry of interest from/discussion between various concerned parties to continue Phabricator in some form, one user proposed dropping support for subversion and mercurial (so as to permit pushing directly to a phabricator-managed git repo with "git push" instead of having to use arcanist). There was some push back from others about losing mercurial support but not a single voice against the proposed loss of support for subversion. (Link to the discussion - requires login.)

    Since the fork ("Phorge") has established itself, the only mention to subversion that I can find (in the publicly/guest accessible bits, anyway) is in the list of "projects" for the various components of Phorge. As you might note - a project hasn't been created for subversion, although it is in the list. According to the comments below the list, projects will be created on a "as-needed" basis. So it looks like there's no plan to drop subversion support... but also no-one has stepped forward to express an interest in maintaining it either. (Unlike mercurial, who does have someone.)

    • Like 1
    • Thanks 1
  14. Quote

    JSON.parse: expected ':' after property name in object at line 5 column 2 of the JSON data
    ERROR: Failed to parse 'simulation/data/technologies/budhist_evangelism.json'

    JSON.parse: unexpected character at line 18 column 5 of the JSON data
    ERROR: Failed to parse 'simulation/data/technologies/cavalry_tradition.json'

    JSON.parse: expected ',' or '}' after property value in object at line 9 column 2 of the JSON data
    ERROR: Failed to parse 'simulation/data/auras/units/heroes/bact_hero_menander_3.json'

    Pretty self-explanatory.

     

    Quote

    WARNING: The "structures/bact/storehouse" template has a defined civ of "sele". This does not match the currently selected civ "bact".
    WARNING: The "structures/bact/sentry_tower" template has a defined civ of "sele". This does not match the currently selected civ "bact".
    WARNING: The "structures/bact/wallset_stone" template has a defined civ of "sele". This does not match the currently selected civ "bact".
    WARNING: The "structures/bact/wonder" template has a defined civ of "sele". This does not match the currently selected civ "bact".
    WARNING: The "structures/sele/wall_gate" template has a defined civ of "sele". This does not match the currently selected civ "bact".
    WARNING: The "structures/sele/wall_tower" template has a defined civ of "sele". This does not match the currently selected civ "bact".
    WARNING: The "structures/sele/wall_long" template has a defined civ of "sele". This does not match the currently selected civ "bact".
    WARNING: The "structures/sele/wall_medium" template has a defined civ of "sele". This does not match the currently selected civ "bact".
    WARNING: The "structures/sele/wall_short" template has a defined civ of "sele". This does not match the currently selected civ "bact".
    WARNING: The "structures/bact/wall_gate" template has a defined civ of "sele". This does not match the currently selected civ "bact".

    Please specify the correct civ within your structure templates.

     

    Quote

    ERROR: CCacheLoader failed to find archived or source file for: "simulation/templates/units/bact/infantry_javelineer_b.xml"
    ERROR: Failed to load entity template 'units/bact/infantry_javelineer_b'

    Either provide the missing template, or provide a suitable alternative under SkirmishReplacements in simulation/data/civs/bact.json.

    • Thanks 1
×
×
  • Create New...