Package Details: ares-emu-git 143.r72.ga247271e3-1

Git Clone URL: https://aur.archlinux.org/ares-emu-git.git (read-only, click to copy)
Package Base: ares-emu-git
Description: Cross-platform, open source, multi-system emulator by Near and Ares team, focusing on accuracy and preservation. (git version)
Upstream URL: https://ares-emu.net/
Licenses: ISC
Conflicts: ares-emu
Provides: ares-emu
Submitter: Snowstorm64
Maintainer: Snowstorm64 (SoullessSentinel)
Last Packager: Snowstorm64
Votes: 4
Popularity: 0.012707
First Submitted: 2021-07-07 14:26 (UTC)
Last Updated: 2025-04-16 21:26 (UTC)

Dependencies (27)

Required by (0)

Sources (1)

Latest Comments

1 2 3 Next › Last »

Snowstorm64 commented on 2025-01-03 17:11 (UTC) (edited on 2025-01-03 17:13 (UTC) by Snowstorm64)

Hi everyone, thanks for your response. However, I would like to make a few things clear:

  • While it's true that my intention is to stay aligned to the upstream but, now that the they adopted CMake, I couldn't see the reason anymore to not allow users some flexibility on how they build the package. Unfortunately it appears now that this isn't always possible, and I won't try to accomodate everyone at any cost.

  • The 'complicated additional options' has nothing to do with CMake's build type, but rather they were a workaround to an issue I have had with how CMake typically handles CFLAGS/CXXFLAGS (they are only passed and stored once, at the configuration time). In any case I have already said I'll remove them soon, along with MAKEFLAGS and ccache option, so that's the end of this discussion.

  • I didn't see any issues with RelWithDebInfo which sets -O2 and not -O3, this is what it counts. However I'll change it to None soon as recommended, but I should point out that it won't make much difference, as the aforementioned flag was already overrideable by CFLAGS/CXXFLAGS before. And then there's the fact that even with None it will still append a lot of other flags to the compiler, and these ones aren't overrideable per upstream's decision.

  • Before anyone asks about building with gcc, there are some known issues that need to be resolved before I can lift off clang/lld requirements though they are the upstream project's recommended way.

FabioLolix commented on 2025-01-02 15:25 (UTC)

I have read about the CMake package guidelines. It seems that nowhere it's written that one must set -D CMAKE_BUILD_TYPE=None

https://wiki.archlinux.org/title/CMake_package_guidelines

2.1.2 Fixing the automatic optimization flag override
[...]
The default CMake build type is None and it does not append any flags to CFLAGS and CXXFLAGS by default

Snowstorm64 commented on 2025-01-02 15:22 (UTC) (edited on 2025-01-02 15:22 (UTC) by Snowstorm64)

Hi xiota, I have read about the CMake package guidelines. It seems that nowhere it's written that one must set -D CMAKE_BUILD_TYPE=None regardless, just that its use is recommended to avoid that unwanted -O3 optimization flag that would be set automatically with CMAKE_BUILD_TYPE=Release. In this case, though, it's the build type RelWithDebInfo that is being used here and that it sets -O2 not -O3, this is what the upstream uses by default anyways. Don't you agree?

However, I will simplify the PKGBUILD as per request, removing the options for CFLAGS and company (despite the reason stated before for putting them in first instance). I'll remove MAKEFLAGS too, looks like it's impossible to make everyone happy...This applies the same to ccache too, at this point if one doesn't want to use ccache then this should be uninstalled, in any case it shouldn't be a problem for CMake.

Snowstorm64 commented on 2025-01-01 21:19 (UTC)

Thank you, I have updated the PKGBUILD accordingly. It should be okay now. Should CFLAGS and other flags start to give issues, I'll take care of them too.

patlefort commented on 2025-01-01 14:09 (UTC) (edited on 2025-01-01 14:20 (UTC) by patlefort)

Ninja doesn't support all the possible MAKEFLAGS. For example, it will cause problem if I use gnu make job server that will fill MAKEFLAGS with stuff that ninja doesn't understand.

As for the flags, it doesn't hurt, however note that only full clean build is supported.

For ccache, DENABLE_CCACHE=OFF will turn off ccache use in their cmake files but will not prevent its use from makepkg.conf ccache option. That option simply add /usr/lib/ccache/bin to the PATH so any invocation of clang or gcc will use ccache transparently.

EDIT: Removed part about NINJAFLAGS, it's not standard. You could still replace MAKEFLAGS with it though or maybe try parsing MAKEFLAGS for a -j option.

Snowstorm64 commented on 2025-01-01 13:19 (UTC)

Hi patlefort, thanks for your suggestions, though I have some questions first as I genuinely just want to understand:

-MAKEFLAGS, can you describe these issues with ninja, that I am not aware of? It has worked great for me, and I put it as a form of courtesy to whose people that don't appreciate the fact that ninja uses every core of the processor. The variable MAKEFLAGS gives them some form of control on the number of core to be used for building process.

-DCMAKE_C_FLAGS, DCMAKE_CXX_FLAGS and DCMAKE_EXE_LINKER_FLAGS, I agree that these variables are already inherited, though I have had some issues when rebuilding the package, specifically when I change some flags in CFLAGS in makepkg.conf for testing purposes but CMake for some reasons doesn't detect these changes. These CMake parameters apparently forces them, so I left them in place. What's the harm with leaving them in PKGBUILD if they don't cause issues?

-DENABLE_CCACHE=OFF, you're right about the forced use of ccache. I have looked at it, I have forgot that there's a variable controlling the use of ccache in makepkg.conf, so I'll remove ccache from makedepend. Though, isn't -DENABLE_CCACHE=OFF also kinda doing the same thing, but in the opposite way? Isn't it better to leave the choice to users?

patlefort commented on 2025-01-01 07:36 (UTC)

Patch for this package for proposed changes: https://pastebin.com/gjhV4f0L

I also added -DENABLE_CCACHE=OFF because we don't want to force use of ccache in pkgbuilds.

patlefort commented on 2024-12-31 23:46 (UTC)

Can you please remove $MAKEFLAGS statement? It's not useful and it even cause issues when ninja is used. Also, DCMAKE_C_FLAGS, DCMAKE_CXX_FLAGS and DCMAKE_EXE_LINKER_FLAGS will already inherit the env. vars. you are passing to them.

1 2 3 Next › Last »