Re: RFR: 8193017: Import freetype sources into OpenJDK source tree
On Mon, Mar 12, 2018 at 5:58 PM, Magnus Ihse Bursie < magnus.ihse.bur...@oracle.com> wrote: > > On 2018-03-12 14:26, Thomas Stüfe wrote: > >> Yes, I am aware :( Long term I hope windows 32bit gets the same occasional >> love as zero does. I can produce occasional patches if time allows. >> >> But in this case the error was in front of the computer, as Magnus >> pointed, >> I may just have a broken build env. >> > Actually, that was not what I was trying to say. I think there's a bug in > the configure script, but one that perhaps only shows up on 32-bit Windows > when it fails to locate the runtime dll in the "normal" places. Probably > missing "" somewhere. > > Sorry, then I misunderstood you. Yes, this may be. I'll recheck later. ..Thomas > /Magnus > > > > >> Thanks for your fix, btw! removing the freetypelib building hassle is a >> huge step toward an easier windows build setup. >> >> ..thomas >> >> On Sat, Mar 10, 2018 at 5:35 PM, Philip Race >> wrote: >> >> This is a tricky one. Since Oracle no longer ships 32 bit JDKs for any >>> platform for the new releases, then there aren't resources or effort >>> being >>> put into making sure it still builds. Our build systems might still >>> support it, but for how long? >>> It might effectively have to become a "port" that someone outside will >>> step up to maintain. >>> Not as different as AIX .. or as much effort perhaps .. but if someone >>> will do that I expect patches would not be refused. >>> >>> -phil. >>> >>> >>> On 3/9/18, 11:55 PM, Thomas Stüfe wrote: >>> >>> I attempted to test the 32bit build but that seems to have bitrotted, I ran into errors not having anything to do with your change. >
Re: RFR: 8193017: Import freetype sources into OpenJDK source tree
On 2018-03-12 14:26, Thomas Stüfe wrote: Yes, I am aware :( Long term I hope windows 32bit gets the same occasional love as zero does. I can produce occasional patches if time allows. But in this case the error was in front of the computer, as Magnus pointed, I may just have a broken build env. Actually, that was not what I was trying to say. I think there's a bug in the configure script, but one that perhaps only shows up on 32-bit Windows when it fails to locate the runtime dll in the "normal" places. Probably missing "" somewhere. /Magnus Thanks for your fix, btw! removing the freetypelib building hassle is a huge step toward an easier windows build setup. ..thomas On Sat, Mar 10, 2018 at 5:35 PM, Philip Race wrote: This is a tricky one. Since Oracle no longer ships 32 bit JDKs for any platform for the new releases, then there aren't resources or effort being put into making sure it still builds. Our build systems might still support it, but for how long? It might effectively have to become a "port" that someone outside will step up to maintain. Not as different as AIX .. or as much effort perhaps .. but if someone will do that I expect patches would not be refused. -phil. On 3/9/18, 11:55 PM, Thomas Stüfe wrote: I attempted to test the 32bit build but that seems to have bitrotted, I ran into errors not having anything to do with your change.
Re: RFR: 8193017: Import freetype sources into OpenJDK source tree
Ok, looks fine. On 09/03/2018 15:52, Philip Race wrote: It is correct as is .. -phil. On 3/9/18, 3:49 PM, Sergey Bylokhov wrote: I am not an expert here, but the LICENSE.TXT is a little bit different. It states that "This means that *you* must choose *one* of the two licenses described below,.". So I do not know should we select the license and provide the text only for one or for both. On 09/03/2018 15:28, Philip Race wrote: Just to be clear, I mean we don't import it to each of the source files. But it is there in the file legal/freetype.md in this webrev. On 3/9/18, 3:26 PM, Philip Race wrote: No. -phil. On 3/9/18, 3:23 PM, Sergey Bylokhov wrote: Hi, Phil Headers of the new files refer to LICENSE.TXT. Should we import it as well? On 09/03/2018 14:10, Phil Race wrote: Bug: https://bugs.openjdk.java.net/browse/JDK-8193017 Webrev: http://cr.openjdk.java.net/~prr/8193017/index.html This fix is will make building openjdk somewhat easier as it removes the dependence on an OpenJDK developer on Windows or Mac going off and downloading and building freetype source themselves .. or using XQuartz on Mac etc. It also means it will be somewhat easier for updating official OpenJDK builds to use a more modern freetype. The pre-compiled binary is a pain inside Oracle too. On Linux and Solaris platforms the build will still default to using the system installed freetype library. However this can easily be over-ridden by adding a configure parameter : --with-freetype=bundled The other valid option being "system" which, is of however never not valid on Windows or Mac. So --with-freetype include is no longer a path. The auto-discovery of the location of system library and headers has worked for me on Solaris and OEL/RHEL as well as Ubuntu 17.10 But just in case it doesn't you can also still use --with-freetype-include and --with-freetype-lib which must both be specified and imply --with-freetype=system The docs have been updated to remove discussion of the obsoleted requirements Sharp eyes will also notice that it now makes Freetype the preferred rasteriser over the closed source T2K, even for Oracle JDK builds : http://cr.openjdk.java.net/~prr/8193017/src/java.desktop/share/classes/sun/font/FontScaler.java.sdiff.html Since freetype != t2k there *will* be some very minor rasterization differences. Such cases are likely not a bug, but a feature :-) Since we previously and now mostly used GDI for LCD text on Windows and also generally defer to CoreText on Mac, the importance of the differences may not be great. But if you see any really bad rendering (I haven't) let me know. make/devkit/createMacosxDevkit6.sh is an empty diff .. I was proposing to remove the devkit references to freetype but it was suggested to leave that alone for now. 99% of the change is simply importing the freetype 2.9 files "as is" The UPDATING.txt file provides some background on the import process. I have built this every-which-way and tested it too .. it is of course possible there's a problem I've missed so try it out yourself if you can. -phil. -- Best regards, Sergey.
Re: RFR: 8193017: Import freetype sources into OpenJDK source tree
Yes, I am aware :( Long term I hope windows 32bit gets the same occasional love as zero does. I can produce occasional patches if time allows. But in this case the error was in front of the computer, as Magnus pointed, I may just have a broken build env. Thanks for your fix, btw! removing the freetypelib building hassle is a huge step toward an easier windows build setup. ..thomas On Sat, Mar 10, 2018 at 5:35 PM, Philip Race wrote: > This is a tricky one. Since Oracle no longer ships 32 bit JDKs for any > platform for the new releases, then there aren't resources or effort being > put into making sure it still builds. Our build systems might still > support it, but for how long? > It might effectively have to become a "port" that someone outside will > step up to maintain. > Not as different as AIX .. or as much effort perhaps .. but if someone > will do that I expect patches would not be refused. > > -phil. > > > On 3/9/18, 11:55 PM, Thomas Stüfe wrote: > >> I attempted to test the 32bit build but that seems to have bitrotted, I >> ran into errors not having anything to do with your change. >> >
Re: RFR: 8193017: Import freetype sources into OpenJDK source tree
This is a tricky one. Since Oracle no longer ships 32 bit JDKs for any platform for the new releases, then there aren't resources or effort being put into making sure it still builds. Our build systems might still support it, but for how long? It might effectively have to become a "port" that someone outside will step up to maintain. Not as different as AIX .. or as much effort perhaps .. but if someone will do that I expect patches would not be refused. -phil. On 3/9/18, 11:55 PM, Thomas Stüfe wrote: I attempted to test the 32bit build but that seems to have bitrotted, I ran into errors not having anything to do with your change.
Re: RFR: 8193017: Import freetype sources into OpenJDK source tree
Hi Phil, This is a nice change! And will make setting up the windows build env much easier. Change itself seems fine at a cursory glance. I also tested the build on Win7 with VS2013 (before, I used to build with a hand-compiled version of the freetypelib), and it worked fine. I attempted to test the 32bit build but that seems to have bitrotted, I ran into errors not having anything to do with your change. Best Regards, Thomas On Fri, Mar 9, 2018 at 11:10 PM, Phil Race wrote: > Bug: https://bugs.openjdk.java.net/browse/JDK-8193017 > Webrev: http://cr.openjdk.java.net/~prr/8193017/index.html > > This fix is will make building openjdk somewhat easier as it removes > the dependence on an OpenJDK developer on Windows or Mac going > off and downloading and building freetype source themselves .. or > using XQuartz on Mac etc. > > It also means it will be somewhat easier for updating official OpenJDK > builds to use a more modern freetype. The pre-compiled binary is a pain > inside Oracle too. > > On Linux and Solaris platforms the build will still default to using > the system installed freetype library. However this can easily be > over-ridden by adding a configure parameter : --with-freetype=bundled > The other valid option being "system" which, is of however never not valid > on Windows or Mac. So --with-freetype include is no longer a path. > The auto-discovery of the location of system library and headers has > worked for me on Solaris and OEL/RHEL as well as Ubuntu 17.10 > > But just in case it doesn't you can also still use > --with-freetype-include and --with-freetype-lib > which must both be specified and imply --with-freetype=system > > The docs have been updated to remove discussion of the obsoleted > requirements > > Sharp eyes will also notice that it now makes Freetype the preferred > rasteriser > over the closed source T2K, even for Oracle JDK builds : > > http://cr.openjdk.java.net/~prr/8193017/src/java.desktop/sha > re/classes/sun/font/FontScaler.java.sdiff.html > > Since freetype != t2k there *will* be some very minor rasterization > differences. > Such cases are likely not a bug, but a feature :-) > Since we previously and now mostly used GDI for LCD text on Windows and > also generally defer to CoreText on Mac, the importance of the differences > may not be great. > But if you see any really bad rendering (I haven't) let me know. > > make/devkit/createMacosxDevkit6.sh is an empty diff .. I was > proposing to remove the devkit references to freetype but it was suggested > to leave that alone for now. > > 99% of the change is simply importing the freetype 2.9 files "as is" > The UPDATING.txt file provides some background on the import process. > > I have built this every-which-way and tested it too .. it is of course > possible > there's a problem I've missed so try it out yourself if you can. > > -phil. > > > > > > > >
Re: RFR: 8193017: Import freetype sources into OpenJDK source tree
It is correct as is .. -phil. On 3/9/18, 3:49 PM, Sergey Bylokhov wrote: I am not an expert here, but the LICENSE.TXT is a little bit different. It states that "This means that *you* must choose *one* of the two licenses described below,.". So I do not know should we select the license and provide the text only for one or for both. On 09/03/2018 15:28, Philip Race wrote: Just to be clear, I mean we don't import it to each of the source files. But it is there in the file legal/freetype.md in this webrev. On 3/9/18, 3:26 PM, Philip Race wrote: No. -phil. On 3/9/18, 3:23 PM, Sergey Bylokhov wrote: Hi, Phil Headers of the new files refer to LICENSE.TXT. Should we import it as well? On 09/03/2018 14:10, Phil Race wrote: Bug: https://bugs.openjdk.java.net/browse/JDK-8193017 Webrev: http://cr.openjdk.java.net/~prr/8193017/index.html This fix is will make building openjdk somewhat easier as it removes the dependence on an OpenJDK developer on Windows or Mac going off and downloading and building freetype source themselves .. or using XQuartz on Mac etc. It also means it will be somewhat easier for updating official OpenJDK builds to use a more modern freetype. The pre-compiled binary is a pain inside Oracle too. On Linux and Solaris platforms the build will still default to using the system installed freetype library. However this can easily be over-ridden by adding a configure parameter : --with-freetype=bundled The other valid option being "system" which, is of however never not valid on Windows or Mac. So --with-freetype include is no longer a path. The auto-discovery of the location of system library and headers has worked for me on Solaris and OEL/RHEL as well as Ubuntu 17.10 But just in case it doesn't you can also still use --with-freetype-include and --with-freetype-lib which must both be specified and imply --with-freetype=system The docs have been updated to remove discussion of the obsoleted requirements Sharp eyes will also notice that it now makes Freetype the preferred rasteriser over the closed source T2K, even for Oracle JDK builds : http://cr.openjdk.java.net/~prr/8193017/src/java.desktop/share/classes/sun/font/FontScaler.java.sdiff.html Since freetype != t2k there *will* be some very minor rasterization differences. Such cases are likely not a bug, but a feature :-) Since we previously and now mostly used GDI for LCD text on Windows and also generally defer to CoreText on Mac, the importance of the differences may not be great. But if you see any really bad rendering (I haven't) let me know. make/devkit/createMacosxDevkit6.sh is an empty diff .. I was proposing to remove the devkit references to freetype but it was suggested to leave that alone for now. 99% of the change is simply importing the freetype 2.9 files "as is" The UPDATING.txt file provides some background on the import process. I have built this every-which-way and tested it too .. it is of course possible there's a problem I've missed so try it out yourself if you can. -phil.
Re: RFR: 8193017: Import freetype sources into OpenJDK source tree
I am not an expert here, but the LICENSE.TXT is a little bit different. It states that "This means that *you* must choose *one* of the two licenses described below,.". So I do not know should we select the license and provide the text only for one or for both. On 09/03/2018 15:28, Philip Race wrote: Just to be clear, I mean we don't import it to each of the source files. But it is there in the file legal/freetype.md in this webrev. On 3/9/18, 3:26 PM, Philip Race wrote: No. -phil. On 3/9/18, 3:23 PM, Sergey Bylokhov wrote: Hi, Phil Headers of the new files refer to LICENSE.TXT. Should we import it as well? On 09/03/2018 14:10, Phil Race wrote: Bug: https://bugs.openjdk.java.net/browse/JDK-8193017 Webrev: http://cr.openjdk.java.net/~prr/8193017/index.html This fix is will make building openjdk somewhat easier as it removes the dependence on an OpenJDK developer on Windows or Mac going off and downloading and building freetype source themselves .. or using XQuartz on Mac etc. It also means it will be somewhat easier for updating official OpenJDK builds to use a more modern freetype. The pre-compiled binary is a pain inside Oracle too. On Linux and Solaris platforms the build will still default to using the system installed freetype library. However this can easily be over-ridden by adding a configure parameter : --with-freetype=bundled The other valid option being "system" which, is of however never not valid on Windows or Mac. So --with-freetype include is no longer a path. The auto-discovery of the location of system library and headers has worked for me on Solaris and OEL/RHEL as well as Ubuntu 17.10 But just in case it doesn't you can also still use --with-freetype-include and --with-freetype-lib which must both be specified and imply --with-freetype=system The docs have been updated to remove discussion of the obsoleted requirements Sharp eyes will also notice that it now makes Freetype the preferred rasteriser over the closed source T2K, even for Oracle JDK builds : http://cr.openjdk.java.net/~prr/8193017/src/java.desktop/share/classes/sun/font/FontScaler.java.sdiff.html Since freetype != t2k there *will* be some very minor rasterization differences. Such cases are likely not a bug, but a feature :-) Since we previously and now mostly used GDI for LCD text on Windows and also generally defer to CoreText on Mac, the importance of the differences may not be great. But if you see any really bad rendering (I haven't) let me know. make/devkit/createMacosxDevkit6.sh is an empty diff .. I was proposing to remove the devkit references to freetype but it was suggested to leave that alone for now. 99% of the change is simply importing the freetype 2.9 files "as is" The UPDATING.txt file provides some background on the import process. I have built this every-which-way and tested it too .. it is of course possible there's a problem I've missed so try it out yourself if you can. -phil. -- Best regards, Sergey.
Re: RFR: 8193017: Import freetype sources into OpenJDK source tree
Just to be clear, I mean we don't import it to each of the source files. But it is there in the file legal/freetype.md in this webrev. On 3/9/18, 3:26 PM, Philip Race wrote: No. -phil. On 3/9/18, 3:23 PM, Sergey Bylokhov wrote: Hi, Phil Headers of the new files refer to LICENSE.TXT. Should we import it as well? On 09/03/2018 14:10, Phil Race wrote: Bug: https://bugs.openjdk.java.net/browse/JDK-8193017 Webrev: http://cr.openjdk.java.net/~prr/8193017/index.html This fix is will make building openjdk somewhat easier as it removes the dependence on an OpenJDK developer on Windows or Mac going off and downloading and building freetype source themselves .. or using XQuartz on Mac etc. It also means it will be somewhat easier for updating official OpenJDK builds to use a more modern freetype. The pre-compiled binary is a pain inside Oracle too. On Linux and Solaris platforms the build will still default to using the system installed freetype library. However this can easily be over-ridden by adding a configure parameter : --with-freetype=bundled The other valid option being "system" which, is of however never not valid on Windows or Mac. So --with-freetype include is no longer a path. The auto-discovery of the location of system library and headers has worked for me on Solaris and OEL/RHEL as well as Ubuntu 17.10 But just in case it doesn't you can also still use --with-freetype-include and --with-freetype-lib which must both be specified and imply --with-freetype=system The docs have been updated to remove discussion of the obsoleted requirements Sharp eyes will also notice that it now makes Freetype the preferred rasteriser over the closed source T2K, even for Oracle JDK builds : http://cr.openjdk.java.net/~prr/8193017/src/java.desktop/share/classes/sun/font/FontScaler.java.sdiff.html Since freetype != t2k there *will* be some very minor rasterization differences. Such cases are likely not a bug, but a feature :-) Since we previously and now mostly used GDI for LCD text on Windows and also generally defer to CoreText on Mac, the importance of the differences may not be great. But if you see any really bad rendering (I haven't) let me know. make/devkit/createMacosxDevkit6.sh is an empty diff .. I was proposing to remove the devkit references to freetype but it was suggested to leave that alone for now. 99% of the change is simply importing the freetype 2.9 files "as is" The UPDATING.txt file provides some background on the import process. I have built this every-which-way and tested it too .. it is of course possible there's a problem I've missed so try it out yourself if you can. -phil.
Re: RFR: 8193017: Import freetype sources into OpenJDK source tree
No. -phil. On 3/9/18, 3:23 PM, Sergey Bylokhov wrote: Hi, Phil Headers of the new files refer to LICENSE.TXT. Should we import it as well? On 09/03/2018 14:10, Phil Race wrote: Bug: https://bugs.openjdk.java.net/browse/JDK-8193017 Webrev: http://cr.openjdk.java.net/~prr/8193017/index.html This fix is will make building openjdk somewhat easier as it removes the dependence on an OpenJDK developer on Windows or Mac going off and downloading and building freetype source themselves .. or using XQuartz on Mac etc. It also means it will be somewhat easier for updating official OpenJDK builds to use a more modern freetype. The pre-compiled binary is a pain inside Oracle too. On Linux and Solaris platforms the build will still default to using the system installed freetype library. However this can easily be over-ridden by adding a configure parameter : --with-freetype=bundled The other valid option being "system" which, is of however never not valid on Windows or Mac. So --with-freetype include is no longer a path. The auto-discovery of the location of system library and headers has worked for me on Solaris and OEL/RHEL as well as Ubuntu 17.10 But just in case it doesn't you can also still use --with-freetype-include and --with-freetype-lib which must both be specified and imply --with-freetype=system The docs have been updated to remove discussion of the obsoleted requirements Sharp eyes will also notice that it now makes Freetype the preferred rasteriser over the closed source T2K, even for Oracle JDK builds : http://cr.openjdk.java.net/~prr/8193017/src/java.desktop/share/classes/sun/font/FontScaler.java.sdiff.html Since freetype != t2k there *will* be some very minor rasterization differences. Such cases are likely not a bug, but a feature :-) Since we previously and now mostly used GDI for LCD text on Windows and also generally defer to CoreText on Mac, the importance of the differences may not be great. But if you see any really bad rendering (I haven't) let me know. make/devkit/createMacosxDevkit6.sh is an empty diff .. I was proposing to remove the devkit references to freetype but it was suggested to leave that alone for now. 99% of the change is simply importing the freetype 2.9 files "as is" The UPDATING.txt file provides some background on the import process. I have built this every-which-way and tested it too .. it is of course possible there's a problem I've missed so try it out yourself if you can. -phil.
Re: RFR: 8193017: Import freetype sources into OpenJDK source tree
Hi, Phil Headers of the new files refer to LICENSE.TXT. Should we import it as well? On 09/03/2018 14:10, Phil Race wrote: Bug: https://bugs.openjdk.java.net/browse/JDK-8193017 Webrev: http://cr.openjdk.java.net/~prr/8193017/index.html This fix is will make building openjdk somewhat easier as it removes the dependence on an OpenJDK developer on Windows or Mac going off and downloading and building freetype source themselves .. or using XQuartz on Mac etc. It also means it will be somewhat easier for updating official OpenJDK builds to use a more modern freetype. The pre-compiled binary is a pain inside Oracle too. On Linux and Solaris platforms the build will still default to using the system installed freetype library. However this can easily be over-ridden by adding a configure parameter : --with-freetype=bundled The other valid option being "system" which, is of however never not valid on Windows or Mac. So --with-freetype include is no longer a path. The auto-discovery of the location of system library and headers has worked for me on Solaris and OEL/RHEL as well as Ubuntu 17.10 But just in case it doesn't you can also still use --with-freetype-include and --with-freetype-lib which must both be specified and imply --with-freetype=system The docs have been updated to remove discussion of the obsoleted requirements Sharp eyes will also notice that it now makes Freetype the preferred rasteriser over the closed source T2K, even for Oracle JDK builds : http://cr.openjdk.java.net/~prr/8193017/src/java.desktop/share/classes/sun/font/FontScaler.java.sdiff.html Since freetype != t2k there *will* be some very minor rasterization differences. Such cases are likely not a bug, but a feature :-) Since we previously and now mostly used GDI for LCD text on Windows and also generally defer to CoreText on Mac, the importance of the differences may not be great. But if you see any really bad rendering (I haven't) let me know. make/devkit/createMacosxDevkit6.sh is an empty diff .. I was proposing to remove the devkit references to freetype but it was suggested to leave that alone for now. 99% of the change is simply importing the freetype 2.9 files "as is" The UPDATING.txt file provides some background on the import process. I have built this every-which-way and tested it too .. it is of course possible there's a problem I've missed so try it out yourself if you can. -phil. -- Best regards, Sergey.
Re: RFR: 8193017: Import freetype sources into OpenJDK source tree
Build changes look good. /Erik On 2018-03-09 14:10, Phil Race wrote: Bug: https://bugs.openjdk.java.net/browse/JDK-8193017 Webrev: http://cr.openjdk.java.net/~prr/8193017/index.html This fix is will make building openjdk somewhat easier as it removes the dependence on an OpenJDK developer on Windows or Mac going off and downloading and building freetype source themselves .. or using XQuartz on Mac etc. It also means it will be somewhat easier for updating official OpenJDK builds to use a more modern freetype. The pre-compiled binary is a pain inside Oracle too. On Linux and Solaris platforms the build will still default to using the system installed freetype library. However this can easily be over-ridden by adding a configure parameter : --with-freetype=bundled The other valid option being "system" which, is of however never not valid on Windows or Mac. So --with-freetype include is no longer a path. The auto-discovery of the location of system library and headers has worked for me on Solaris and OEL/RHEL as well as Ubuntu 17.10 But just in case it doesn't you can also still use --with-freetype-include and --with-freetype-lib which must both be specified and imply --with-freetype=system The docs have been updated to remove discussion of the obsoleted requirements Sharp eyes will also notice that it now makes Freetype the preferred rasteriser over the closed source T2K, even for Oracle JDK builds : http://cr.openjdk.java.net/~prr/8193017/src/java.desktop/share/classes/sun/font/FontScaler.java.sdiff.html Since freetype != t2k there *will* be some very minor rasterization differences. Such cases are likely not a bug, but a feature :-) Since we previously and now mostly used GDI for LCD text on Windows and also generally defer to CoreText on Mac, the importance of the differences may not be great. But if you see any really bad rendering (I haven't) let me know. make/devkit/createMacosxDevkit6.sh is an empty diff .. I was proposing to remove the devkit references to freetype but it was suggested to leave that alone for now. 99% of the change is simply importing the freetype 2.9 files "as is" The UPDATING.txt file provides some background on the import process. I have built this every-which-way and tested it too .. it is of course possible there's a problem I've missed so try it out yourself if you can. -phil.
