Closed Bug 717499 Opened 11 years ago Closed 10 years ago

"gfxWindowsPlatform.cpp(485) : error C2065: 'gfxDWriteFont' : undeclared identifier" when using "--with-windows-version=502"

Categories

(Core :: Graphics, defect)

x86
Windows Server 2003
defect
Not set
blocker

Tracking

()

RESOLVED INVALID
Tracking Status
firefox9 --- wontfix
firefox10 --- wontfix
firefox11 - wontfix
firefox12 --- wontfix
firefox-esr10 --- wontfix

People

(Reporter: sgautherie, Assigned: neil)

References

()

Details

(Keywords: regression)

Attachments

(1 file)

(Found while trying to reproduce bug 716449.)

https://tbpl.mozilla.org/?tree=Try&rev=790b578ddb7c
https://tbpl.mozilla.org/php/getParsedLog.php?id=8492165&tree=Try&full=1
WINNT 5.2 try build on 2012-01-11 15:22:30 PST for push 790b578ddb7c
https://tbpl.mozilla.org/php/getParsedLog.php?id=8491803&tree=Try&full=1
WINNT 5.2 try leak test build on 2012-01-11 15:22:30 PST for push 790b578ddb7c
{
.../gfx/thebes/gfxWindowsPlatform.cpp(485) : error C2065: 'gfxDWriteFont' : undeclared identifier
...
}

I see Neil already attached a (unreviewed) patch in bug 651858 6 months ago :-/
Code should be "fixed", or bug 629827 !
Bug 651858 patch 543379, unbitrotted.

Succeeded as https://tbpl.mozilla.org/?tree=Try&rev=ce1c31e55fe1 (12a1)


Bug 651858 comment 121:
{{
neil@parkwaycc.co.uk      2011-07-01 01:56:48 PDT

*_D2D_SURFACE are only defined if you are using the Windows 7 SDK, so they can replace the uses of XP_WIN. The only place I had to move things around was gfxWindowsPlatform, which I suspect is only compiled on Windows anyway...
}}

Bug 651858 comment 122:
{{
Bas Schouten (:bas) 2011-07-01 04:31:57 PDT

Review of attachment 543379 [details] [diff] [review] [diff] [review]:
-----------------------------------------------------------------

::: gfx/2d/Factory.cpp
@@ +40,5 @@
>  #ifdef USE_CAIRO
>  #include "DrawTargetCairo.h"
>  #endif
>  
> +#ifdef CAIRO_HAS_D2D_SURFACE

This is a bit of an issue since this isn't present in the Azure stand-alone build (and shouldn't be named that way). We should rename this #define to USE_DIRECT2D or something and then define that before including this file in gfxPlatform inside #ifdef CAIRO_HAS_D2D_SURFACE.
}}

I would be willing to fix that, though I would need more details about what is wanted precisely.
Attachment #590649 - Flags: review?(bas.schouten)
Attachment #590649 - Flags: feedback+
(In reply to Serge Gautherie (:sgautherie) from comment #1)
> Created attachment 590649 [details] [diff] [review]
> (Av1) Fix Direct2D related code compilation with Windows 2003R2/Vista SDKs
> 
> Bug 651858 patch 543379, unbitrotted.
> 
> Succeeded as https://tbpl.mozilla.org/?tree=Try&rev=ce1c31e55fe1 (12a1)
> 
> 
> Bug 651858 comment 121:
> {{
> neil@parkwaycc.co.uk      2011-07-01 01:56:48 PDT
> 
> *_D2D_SURFACE are only defined if you are using the Windows 7 SDK, so they
> can replace the uses of XP_WIN. The only place I had to move things around
> was gfxWindowsPlatform, which I suspect is only compiled on Windows anyway...
> }}
> 
> Bug 651858 comment 122:
> {{
> Bas Schouten (:bas) 2011-07-01 04:31:57 PDT
> 
> Review of attachment 543379 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: gfx/2d/Factory.cpp
> @@ +40,5 @@
> >  #ifdef USE_CAIRO
> >  #include "DrawTargetCairo.h"
> >  #endif
> >  
> > +#ifdef CAIRO_HAS_D2D_SURFACE
> 
> This is a bit of an issue since this isn't present in the Azure stand-alone
> build (and shouldn't be named that way). We should rename this #define to
> USE_DIRECT2D or something and then define that before including this file in
> gfxPlatform inside #ifdef CAIRO_HAS_D2D_SURFACE.
> }}
> 
> I would be willing to fix that, though I would need more details about what
> is wanted precisely.

Basically we should make the Azure portion of the tree build with USE_DIRECT2D defined when the SDK is available. Then I can add USE_DIRECT2D to the Azure stand-alone build.
(In reply to Bas Schouten (:bas) from comment #2)
> Basically we should make the Azure portion of the tree build with
> USE_DIRECT2D defined when the SDK is available. Then I can add USE_DIRECT2D
> to the Azure stand-alone build.

Hum, I am willing to further maintain the patch (as need be), but I know little about Azure (especially what that "portion" is precisely).
Should what you are looking for be done (as) in a blocking bug?

Also, (how) could this bug be fixed for version 10 (especially LTS) and 11?
(In reply to Serge Gautherie (:sgautherie) from comment #3)
> (In reply to Bas Schouten (:bas) from comment #2)
> > Basically we should make the Azure portion of the tree build with
> > USE_DIRECT2D defined when the SDK is available. Then I can add USE_DIRECT2D
> > to the Azure stand-alone build.
> 
> Hum, I am willing to further maintain the patch (as need be), but I know
> little about Azure (especially what that "portion" is precisely).
> Should what you are looking for be done (as) in a blocking bug?
> 
> Also, (how) could this bug be fixed for version 10 (especially LTS) and 11?

I'd be ok with it landing there. Although, personally I'd -much- rather see old SDKs be deprecated since it causes less inconsistencies between builds and build environments. i.e. D2D is only a small example but a windows build without Direct2D simply isn't very realistic, our release builds have it and a significant portion of our Windows 7 users are using it.
Depends on: RequireWin7SDK
No longer depends on: PSDK2003R2Removal
Why does this depend on bug 699385? That bug makes this one pointless instead.
(In reply to Siddharth Agarwal [:sid0] from comment #5)
> Why does this depend on bug 699385? That bug makes this one pointless
> instead.

Bug 699385 obsoleted this bug on Trunk only.
(In reply to Bas Schouten (:bas) from comment #4)
> (In reply to Serge Gautherie (:sgautherie) from comment #3)
> > (In reply to Bas Schouten (:bas) from comment #2)
> > > Basically we should make the Azure portion of the tree build with
> > > USE_DIRECT2D defined when the SDK is available. Then I can add USE_DIRECT2D
> > > to the Azure stand-alone build.
> > 
> > Hum, I am willing to further maintain the patch (as need be), but I know
> > little about Azure (especially what that "portion" is precisely).
> > Should what you are looking for be done (as) in a blocking bug?
> > 
> > Also, (how) could this bug be fixed for version 10 (especially LTS) and 11?

PS: s/LTS/ESR/.

> I'd be ok with it landing there. Although, personally I'd -much- rather see
> old SDKs be deprecated

Older SDKs are now unsupported on mozilla13.
Would you accept this patch for (12) 11 (10)? (Assuming later approvals.)
No need to track for 11, although we'd consider taking a low-risk fix early in the cycle.
Is this still relevant?
No.
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → INVALID
Attachment #590649 - Flags: review?(bas)
You need to log in before you can comment on or make changes to this bug.