Date: Wed, 25 May 2016 16:29:59 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-ports-bugs@FreeBSD.org Subject: [Bug 209742] devel/godot: Improve port (v2.0.3) Message-ID: <bug-209742-13-Z74Y2RETZY@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-209742-13@https.bugs.freebsd.org/bugzilla/> References: <bug-209742-13@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D209742 lightside <lightside@gmx.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #170627|0 |1 is obsolete| | Attachment #170627|maintainer-approval?(FreeBS | Flags|D@ShaneWare.Biz) | Attachment #170630|0 |1 is obsolete| | Attachment #170631|0 |1 is obsolete| | Attachment #170632|0 |1 is obsolete| | Attachment #170633|0 |1 is obsolete| | Attachment #170655| |maintainer-approval?(FreeBS Flags| |D@ShaneWare.Biz) --- Comment #8 from lightside <lightside@gmx.com> --- Created attachment 170655 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D170655&action= =3Dedit Proposed patch (since 415742 revision) Hello. (In reply to comment #7) > I would suggest you consider submitting a patch to update > Mk/bsd.license.db.mk with the CC variations, maybe with a patch that also > updates the various ports that currently have their own CC info. Thanks for suggestion. But, I don't consider this as a priority, currently. There are various CC (Creative Commons) licenses and their versions, while I use just a portion of them for some ports, which I maintain. (In reply to comment #7) > Yes I did forget to install the icon, I think both the svg and png should= be > installed - and always, not just with tools enabled. I think, there is no point to install icon(s), if TOOLS option disabled. The icon.png icon is needed for desktop entry only. Not sure where to install icon.svg. It could be ${PREFIX}/share/icons/hicolor/scalable/apps/godot.svg, but I didn't find a usage of it by desktop environment. Moreover, if icon(s) will be installed independently from TOOLS option, the= n it will block proposed godot-tools port, because of file conflicts. (In reply to comment #7) > Using rtaudio isn't exclusive, it needs the alsa or pulse libs to work. W= hile > enabling rtaudio and using alsa or pulse works for me, godot talking stra= ight > to alsa failed. Actually, it's possible to use RtAudio without ALSA or PulseAudio, then it = will be called as RtAudio-None, so programs, which use audio, could be started (without audio). (In reply to comment #7) > As rtaudio is a few files included with godot it could stay enabled I agree, it could be enabled by default, without option. (In reply to comment #7) > rtaudio also knows about LINUX OSS so if we get that working we could drop > using audio libs from other ports and just use the built-in system sound. I tried to build with "__LINUX_OSS__" define, but it gave following error: drivers/rtaudio/RtAudio.cpp:8700:15: error: use of undeclared identifier 'AFMT_FLOAT' if ( mask & AFMT_FLOAT ) Also, it uses "/dev/mixer" in this case, which I didn't find on FreeBSD sys= tem. (In reply to comment #7) > For now I think leave rtaudio enabled but choose between alsa and pulse > using an OPTION_SINGLE. Actually, it is possible to disable these options, then it will be RtAudio-None. Therefore, this is just a OPTION_GROUP. Also, ALSA and PULSEAUDIO options may be enabled together. I recreated patc= hes for RtAudio driver, which allows to enumerate between them (look RtAudio::RtAudio(RtAudio::Api api) constructor on https://github.com/godotengine/godot/blob/2.0.3-stable/drivers/rtaudio/RtAu= dio.cpp#L197). But this could name a RtAudio-ALSA-PulseAudio driver in case of ALSA and PULSEAUDIO enabled together (ALSA checked first, then PULSEAUDIO). Still not sure, if this is practical (and better to use previous variant). (In reply to comment #7) > As for the extra tools port - I don't think there is a need for that. The > build with the tools enabled works as a runtime. Although I do see a build > without tools being useful, at this stage we don't have the games availab= le > for people to use a runtime only build. I had thought of removing tools f= rom > default once there are some games available, for now anyone installing go= dot > is installing to use the tools to make a game. There is a games/tanks-of-freedom port available, which may use just a runt= ime, e.g. with target=3Drelease, instead of target=3Ddebug, which tools=3Dyes pr= ovide, currently. In practice, I even found how to build runtime and tools in the = same godot port (with using do-build-TOOLS-on stage and modified DO_MAKE_BUILD command), because of different suffixes they use. But considering the users, which may use packages only, the godot and godot-tools ports are complete (runtime and tools) with default options. The important part is a SYMLINKSU= FFIX variable, which godot-tools use, to not conflict between ports. But if you think otherwise, I can remove it from proposal, then it will be as current variant (without a multiple choice on the same computer). Thanks for your attention. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-209742-13-Z74Y2RETZY>