[GIT PULL FOR v3.2] Compilation fixes

[GIT PULL FOR v3.2] Compilation fixes

[Hans Verkuil]

Mauro,

This fixes two compilation problems when using the media_build system.

Both gspca and the solo driver have a header with the same name, and that
clashes when using media_build.

And the solo driver uses an incorrect Makefile construct, which (somewhat
mysteriously) skips the compilation of 90% of all media drivers.

Hopefully this pull request makes it to patchwork as well.

Regards,

        Hans


The following changes since commit bd90649834a322ff70925db9ac37bf7a461add52:

  staging/Makefile: Don't compile a media driver there (2011-11-02 09:17:00 -0200)

are available in the git repository at:
  git://linuxtv.org/hverkuil/media_tree.git fixes

Hans Verkuil (2):
      solo6x10: rename jpeg.h to solo6x10-jpeg.h
      solo6x10: fix broken Makefile

 drivers/staging/media/solo6x10/Makefile            |    2 +-
 .../media/solo6x10/{jpeg.h => solo6x10-jpeg.h}     |    0
 drivers/staging/media/solo6x10/v4l2-enc.c          |    2 +-
 3 files changed, 2 insertions(+), 2 deletions(-)
 rename drivers/staging/media/solo6x10/{jpeg.h => solo6x10-jpeg.h} (100%)

Re: [GIT PULL FOR v3.2] Compilation fixes

[Mauro Carvalho Chehab]

Em 04-11-2011 07:39, Hans Verkuil escreveu:
> Mauro,
> 
> This fixes two compilation problems when using the media_build system.
> 
> Both gspca and the solo driver have a header with the same name, and that
> clashes when using media_build.

This the kind of patch that doesn't make much sense upstream. Granted, the
files weren't properly named, but there's not requirement upstream that
denies naming two different files with the same name.

Btw, looking at both, it seems that they can be merged: both defines the jpeg
header. The basic difference is that, while gspca jpeg header can have a size of
either 556 or 589 bytes, the one at solo6x10 has 575 bytes.

IMHO, the proper fix is to make solo6x10 driver to use the gspca jpeg.h header.
Assuming that this driver would find his way out of staging, then the jpeg.h
file should also be moved to another place, like include/linux/media, as I
don't think that solo6x10 driver should be a gspca sub-driver.

Hans G, what do you think?

> And the solo driver uses an incorrect Makefile construct, which (somewhat
> mysteriously) skips the compilation of 90% of all media drivers.

Hmm.. probably they're using "=" or ":=" instead of "+=". While this works at 
leaf Makefiles, this breaks compilation when there's just one Makefile, or
when you add another thing to be compiled there. This is something that requires
a fix.

> 
> Hopefully this pull request makes it to patchwork as well.
> 
> Regards,
> 
>         Hans
> 
> 
> The following changes since commit bd90649834a322ff70925db9ac37bf7a461add52:
> 
>   staging/Makefile: Don't compile a media driver there (2011-11-02 09:17:00 -0200)
> 
> are available in the git repository at:
>   git://linuxtv.org/hverkuil/media_tree.git fixes
> 
> Hans Verkuil (2):
>       solo6x10: rename jpeg.h to solo6x10-jpeg.h
>       solo6x10: fix broken Makefile
> 
>  drivers/staging/media/solo6x10/Makefile            |    2 +-
>  .../media/solo6x10/{jpeg.h => solo6x10-jpeg.h}     |    0
>  drivers/staging/media/solo6x10/v4l2-enc.c          |    2 +-
>  3 files changed, 2 insertions(+), 2 deletions(-)
>  rename drivers/staging/media/solo6x10/{jpeg.h => solo6x10-jpeg.h} (100%)

Re: [GIT PULL FOR v3.2] Compilation fixes

[Mauro Carvalho Chehab]

Em 04-11-2011 08:13, Mauro Carvalho Chehab escreveu:
> Em 04-11-2011 07:39, Hans Verkuil escreveu:
>> Mauro,
>>
>> This fixes two compilation problems when using the media_build system.
>>
>> Both gspca and the solo driver have a header with the same name, and that
>> clashes when using media_build.
> 
> This the kind of patch that doesn't make much sense upstream. Granted, the
> files weren't properly named, but there's not requirement upstream that
> denies naming two different files with the same name.
> 
> Btw, looking at both, it seems that they can be merged: both defines the jpeg
> header. The basic difference is that, while gspca jpeg header can have a size of
> either 556 or 589 bytes, the one at solo6x10 has 575 bytes.
> 
> IMHO, the proper fix is to make solo6x10 driver to use the gspca jpeg.h header.
> Assuming that this driver would find his way out of staging, then the jpeg.h
> file should also be moved to another place, like include/linux/media, as I
> don't think that solo6x10 driver should be a gspca sub-driver.
> 
> Hans G, what do you think?

The quantization tables are completely different on Solo driver. Merging them
will probably be very messy. I withdraw the proposal of merging them.

Your patch makes sense to me.

> 
>> And the solo driver uses an incorrect Makefile construct, which (somewhat
>> mysteriously) skips the compilation of 90% of all media drivers.
> 
> Hmm.. probably they're using "=" or ":=" instead of "+=". While this works at 
> leaf Makefiles, this breaks compilation when there's just one Makefile, or
> when you add another thing to be compiled there. This is something that requires
> a fix.
> 
>>
>> Hopefully this pull request makes it to patchwork as well.
>>
>> Regards,
>>
>>         Hans
>>
>>
>> The following changes since commit bd90649834a322ff70925db9ac37bf7a461add52:
>>
>>   staging/Makefile: Don't compile a media driver there (2011-11-02 09:17:00 -0200)
>>
>> are available in the git repository at:
>>   git://linuxtv.org/hverkuil/media_tree.git fixes
>>
>> Hans Verkuil (2):
>>       solo6x10: rename jpeg.h to solo6x10-jpeg.h
>>       solo6x10: fix broken Makefile
>>
>>  drivers/staging/media/solo6x10/Makefile            |    2 +-
>>  .../media/solo6x10/{jpeg.h => solo6x10-jpeg.h}     |    0
>>  drivers/staging/media/solo6x10/v4l2-enc.c          |    2 +-
>>  3 files changed, 2 insertions(+), 2 deletions(-)
>>  rename drivers/staging/media/solo6x10/{jpeg.h => solo6x10-jpeg.h} (100%)
> 

Re: [GIT PULL FOR v3.2] Compilation fixes

[Hans Verkuil]

On Friday 04 November 2011 11:19:37 Mauro Carvalho Chehab wrote:
> Em 04-11-2011 08:13, Mauro Carvalho Chehab escreveu:
> > Em 04-11-2011 07:39, Hans Verkuil escreveu:
> >> Mauro,
> >> 
> >> This fixes two compilation problems when using the media_build system.
> >> 
> >> Both gspca and the solo driver have a header with the same name, and
> >> that clashes when using media_build.
> > 
> > This the kind of patch that doesn't make much sense upstream. Granted,
> > the files weren't properly named, but there's not requirement upstream
> > that denies naming two different files with the same name.
> > 
> > Btw, looking at both, it seems that they can be merged: both defines the
> > jpeg header. The basic difference is that, while gspca jpeg header can
> > have a size of either 556 or 589 bytes, the one at solo6x10 has 575
> > bytes.
> > 
> > IMHO, the proper fix is to make solo6x10 driver to use the gspca jpeg.h
> > header. Assuming that this driver would find his way out of staging,
> > then the jpeg.h file should also be moved to another place, like
> > include/linux/media, as I don't think that solo6x10 driver should be a
> > gspca sub-driver.
> > 
> > Hans G, what do you think?
> 
> The quantization tables are completely different on Solo driver. Merging
> them will probably be very messy. I withdraw the proposal of merging them.
> 
> Your patch makes sense to me.

OK.

Perhaps the gspca jpeg.h header should be renamed to gspca-jpeg.h as well?

Since the solo driver is in staging I went for just renaming the header in
that driver rather than renaming a header in a non-staging driver.

> >> And the solo driver uses an incorrect Makefile construct, which
> >> (somewhat mysteriously) skips the compilation of 90% of all media
> >> drivers.
> > 
> > Hmm.. probably they're using "=" or ":=" instead of "+=". While this
> > works at leaf Makefiles, this breaks compilation when there's just one
> > Makefile, or when you add another thing to be compiled there. This is
> > something that requires a fix.

That's indeed what I fixed in my second patch (:= -> +=).

	Hans

Re: [GIT PULL FOR v3.2] Compilation fixes

[Mauro Carvalho Chehab]

Em 04-11-2011 08:27, Hans Verkuil escreveu:
> On Friday 04 November 2011 11:19:37 Mauro Carvalho Chehab wrote:
>> Em 04-11-2011 08:13, Mauro Carvalho Chehab escreveu:
>>> Em 04-11-2011 07:39, Hans Verkuil escreveu:
>>>> Mauro,
>>>>
>>>> This fixes two compilation problems when using the media_build system.
>>>>
>>>> Both gspca and the solo driver have a header with the same name, and
>>>> that clashes when using media_build.
>>>
>>> This the kind of patch that doesn't make much sense upstream. Granted,
>>> the files weren't properly named, but there's not requirement upstream
>>> that denies naming two different files with the same name.
>>>
>>> Btw, looking at both, it seems that they can be merged: both defines the
>>> jpeg header. The basic difference is that, while gspca jpeg header can
>>> have a size of either 556 or 589 bytes, the one at solo6x10 has 575
>>> bytes.
>>>
>>> IMHO, the proper fix is to make solo6x10 driver to use the gspca jpeg.h
>>> header. Assuming that this driver would find his way out of staging,
>>> then the jpeg.h file should also be moved to another place, like
>>> include/linux/media, as I don't think that solo6x10 driver should be a
>>> gspca sub-driver.
>>>
>>> Hans G, what do you think?
>>
>> The quantization tables are completely different on Solo driver. Merging
>> them will probably be very messy. I withdraw the proposal of merging them.
>>
>> Your patch makes sense to me.
> 
> OK.
> 
> Perhaps the gspca jpeg.h header should be renamed to gspca-jpeg.h as well?

I think so, as it currently doesn't implement a generic way of generating
jpeg headers.

> Since the solo driver is in staging I went for just renaming the header in
> that driver rather than renaming a header in a non-staging driver.
> 
>>>> And the solo driver uses an incorrect Makefile construct, which
>>>> (somewhat mysteriously) skips the compilation of 90% of all media
>>>> drivers.
>>>
>>> Hmm.. probably they're using "=" or ":=" instead of "+=". While this
>>> works at leaf Makefiles, this breaks compilation when there's just one
>>> Makefile, or when you add another thing to be compiled there. This is
>>> something that requires a fix.
> 
> That's indeed what I fixed in my second patch (:= -> +=).

Ok.

Regards,
Mauro