[FFmpeg-devel] [PATCH v3 0/5] Fix FFmpeg compilation without DCE

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> Carl Eugen Hoyos
> Sent: Sunday, November 27, 2022 6:45 PM
> To: FFmpeg development discussions and patches <ffmpeg-
> devel at ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH v3 0/5] Fix FFmpeg compilation
> without DCE
> 
> Am So., 27. Nov. 2022 um 18:16 Uhr schrieb Soft Works
> <softworkz at hotmail.com>:
> >
> >
> >
> > > -----Original Message-----
> > > From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> > > Carl Eugen Hoyos
> > > Sent: Sunday, November 27, 2022 5:47 PM
> > > To: FFmpeg development discussions and patches <ffmpeg-
> > > devel at ffmpeg.org>
> > > Subject: Re: [FFmpeg-devel] [PATCH v3 0/5] Fix FFmpeg compilation
> > > without DCE
> 
> Please consider fixing your mail client.

What did it do wrong?


> > > Am So., 27. Nov. 2022 um 17:29 Uhr schrieb Soft Works
> > > <softworkz at hotmail.com>:
> > >
> > > > How do you set this up when you are compiling with MSVC?
> > >
> > > My configure line to compile with MSVC is:
> > > $ src/configure --enable-gpl --toolchain=msvc --host-os=win32
> > >
> > > But maybe I misunderstand your question?
> >

> From what I remember, running configure in MSYS literally
> took ages, I don't know if this has improved.

Nope. It's still as horribly long as it was, even with everything
update to latest..

> > What I meant is the environment. Are you running this from
> > an MSYS shell? Or WSL?
> 
> WSL

Ah alright. Probably a better choice when all you need is the scripting
environment.


> > And does running configure output VS project files
> 
> I don't think so.

Sorry, I must have confused this with some external script or
something.
 

I was asking because when it's about msvc, I'm used to picture
someone would be using VS as an IDE. So, yes, the plain msvc
compiler doesn't have a problem with DCE. The problem is when
creating projects to compile and work with the code in the 
VS IDE. And what VS does is pre-parsing the code in the 
background while you're working on it, so you don't really 
need to compile as you see errors and warning while you 
write them. As there's no actual linking being done, this
procedure cannot "simulate" the DCE process and it can only
assume that those symbols that DCE would eliminate are 
missing symbols. The result is that you cannot work in the
IDE because it is full of errors due to this.

Likely, this is also the use case of the submitter of 
this patch.
I'm using VS as well, not for final compilation but 
for writing and debugging as this allows me to work in the
way I want to work. Currently, I'm using Matt Oliver's
VS project generator, which does a really good job in working
around these problems by creating empty definitions for
all these loose ends that are missing (as long as a final
compilation hasn't determined that they aren't actually 
needed.

But this does also have drawbacks: when changes are made
in the ffmpeg base, those definitions may not match
anymore and the projects need to be re-generated (which 
is painful). And the same applies when switching branches,
so I usually have multiple sets of VS project/solutions,
but these still get outdated and I need to re-create 
again.

For these reasons, I would very much welcome when this
situation could be improved. And not only for those but
I also had a situation at some time where I wasted a lot
of time and got quite desperate on something that turned
out to be caused by the code relying on DCE - which wasn't
clear to me in that situation. When you know about it,
then you can live with it, but when not, then it just 
adds to the experience for those who are new to ffmpeg.

Also, I'm not sure whether that is a reasonable use case
for DCE, that it allows you to spare writing a few 
conditionals in the code.

Anyway, I would find it nice if the code would not
rely on DCE anymore.

Best wishes,
softworkz