VLC for PowerPC: make a separate port or modify existing?

[Sergey Fedorov]

Don’t worry, I will not submit a PR for VLC unless it actually works with
video. There is no point otherwise.

If it does not, I just leave it. But for now it still makes sense to
have an idea what to do with the port *IF* it works.

On Sat, Aug 5, 2023 at 7:02 AM Ken Cunningham <
ken.cunningham.webuse at gmail.com> wrote:

> For playing videos on older systems, I think MPlayer is the way to go.
>
> Give that a try if you haven't.
>
> Ken
>
>
> On 2023-08-04, at 3:57 PM, Sergey Fedorov wrote:
>
> I need an advice.
>
> We got VLC2 port (which is totally broken for all systems) and VLC port,
> which installs pre-built binary. Neither supports PPC, obviously, and even
> i386.
>
> Leaving the main VLC aside, VLC2 is already a mess and in the present
> state is unusable for practical purposes. Rewriting the logic is doable (I
> have done it locally, kind of), however I have few concerns here:
>
> 1. Given the complexity of the port, it may not be obvious for anyone who
> might wish to update it in the future or fix something for Intel systems,
> what has to be left untouched for PPC (assuming that testing for PPC cannot
> be done due to lack of hardware). It is very easy to break the build, I
> just now tried to enable a feature which looked harmless, and that broke
> the build immediately. And we cannot really write passages of explanations
> for every change or choice.
>
> 2. On the other hand, even though the port is currently broken for Intel,
> my fixes might introduce some undesirable effects for it, unless of course
> literally everything is put inside the guarding condition. But then we have
> x2 more code in the port, which is already barely readable.
>
> For these reasons, it seems easier and safer to have a separate VLC-ppc
> port: then I can work on it without bothering to match versions or to break
> anything for someone, and at the same time be reasonably sure no one
> accidentally breaks PPC build.
>
> However, we seldom make arch-specific ports, so I assume, it may not be
> considered desirable.
>
> Which way should I go here? Ultimately I am fine with either option, but
> it will save time to decide first rather than having to rewrite later
> something completely.
>
>
> P. S. Re status of the thing itself:
>
> Given that FreeBSD seems to build the current VLC 3.x for 32-bit archs,
> including PPC (may be untested, but still), chances are it can be fixed.
> However, support for Qt4 has to be restored or otherwise Qt should be
> foregone completely.
>
> *Building* of VLC2 I have fixed for PPC tonight. It works in some aspects
> (GUI is acceptably okay, audio output seems perfect), but video either does
> not or works partly (I cannot tests all output modes right now for
> technical reasons).
> So it is not a matter of tomorrow’s PR yet, but if it works, it may work
> rather soon.
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20230805/e5e55d99/attachment-0001.htm>