A couple of questions about the new build system
Kelly O'Hair
kelly.ohair at workday.com
Mon Apr 8 16:00:00 UTC 2013
I think it's /showIncludes ???
http://msdn.microsoft.com/en-us/library/hdkef6tk%28v=vs.100%29.aspx
-kto
On 4/8/13 1:16 AM, "Erik Joelsson" <erik.joelsson at oracle.com> wrote:
>I just realized you are probably running on windows and unfortunately
>this currently doesn't work there. We use the -M flag for gcc which
>outputs make dependency files. The visual studio compiler doesn't have
>this feature. There are ways this can be worked around. I've created
>8011687 to track this issue.
>
>/Erik
>
>On 2013-04-02 10:16, Erik Joelsson wrote:
>>
>>
>> On 2013-03-29 00:00, Phil Race wrote:
>>> > If you touch a header fie, the build is supposed to notice and "do
>>> the right thing".
>>>
>>> It did not do so. If I touched a C file, no problem, but not so for
>>> the header file.
>>> This was observed on Solaris 10 SPARC.
>>>
>> I just tried:
>> touch ../../jdk/src/share/native/sun/font/fontscalerdefs.h
>> make LOG=info
>>
>> which resulted in the following:
>>
>> ...
>> ## Starting jdk
>> Compiling AccelGlyphCache.c (for libawt_xawt.so)
>> Compiling OGLTextRenderer.c (for libawt_xawt.so)
>> Compiling X11FontScaler_md.c (for libawt_xawt.so)
>> Compiling XRBackendNative.c (for libawt_xawt.so)
>> Compiling DrawGlyphList.c (for libfontmanager.so)
>> Compiling FontInstanceAdapter.cpp (for libfontmanager.so)
>> Compiling SunLayoutEngine.cpp (for libfontmanager.so)
>> Compiling X11FontScaler.c (for libfontmanager.so)
>> Compiling sunFont.c (for libfontmanager.so)
>>
>>/localhome/mercurial/closed-jdk8-build/jdk/src/share/native/sun/font/layo
>>ut/SunLayoutEngine.cpp:
>> In function ‘void Java_sun_font_SunLayoutEngine_nativeLayout(JNIEnv*,
>> _jclass*, _jobject*, _jobject*, _jfloatArray*, jint, jint,
>> _jcharArray*, jint, jint, jint, jint, jint, jint, jint, _jobject*,
>> _jobject*, jlong, jlong)’:
>>
>>/localhome/mercurial/closed-jdk8-build/jdk/src/share/native/sun/font/layo
>>ut/SunLayoutEngine.cpp:190:
>> warning: comparison between signed and unsigned integer expressions
>> Compiling GeneralPath.cpp (for libt2k.so)
>> Compiling scalerMethods.c (for libt2k.so)
>> Compiling t2kScalerMethods.cpp (for libt2k.so)
>> Compiling AccelGlyphCache.c (for libawt_headless.so)
>>
>>/localhome/mercurial/closed-jdk8-build/jdk/src/share/native/sun/font/sunF
>>ont.c:
>> In function ‘Java_sun_font_StrikeCache_freeIntPointer’:
>>
>>/localhome/mercurial/closed-jdk8-build/jdk/src/share/native/sun/font/sunF
>>ont.c:196:
>> warning: cast to pointer from integer of different size
>>
>>/localhome/mercurial/closed-jdk8-build/jdk/src/share/native/sun/font/sunF
>>ont.c:
>> In function ‘Java_sun_font_StrikeCache_freeIntMemory’:
>>
>>/localhome/mercurial/closed-jdk8-build/jdk/src/share/native/sun/font/sunF
>>ont.c:234:
>> warning: cast to pointer from integer of different size
>> Compiling X11FontScaler_md.c (for libawt_headless.so)
>> Linking libawt_xawt.so
>> Linking libfontmanager.so
>> Linking libawt_headless.so
>> Linking libt2k.so
>> Linking libjawt.so
>> ...
>>
>> Note that the default verbosity doesn't print anything when compiling
>> native code. You need to increase it to "info" to see what gets
>> recompiled.
>>
>> If this doesn't work for you, it's a bug that needs to be investigated.
>>
>> /Erik
>>
>>> -phil.
>>>
>>> On 3/28/2013 2:45 PM, Jonathan Gibbons wrote:
>>>> On 03/28/2013 02:29 PM, Phil Race wrote:
>>>>> 1. Why do we have both --with-cups and --with-cups-include ?
>>>>> All we use is the header files so the latter is what matters and
>>>>> I'm not sure which one the build system prefers if both are set.
>>>>>
>>>>> 2. In the old build I could do
>>>>> cd make/sun/font
>>>>> make clean
>>>>> make all
>>>>>
>>>>> Is there anything analagous to 'make clean' here,where I can have a
>>>>> level of comfort
>>>>> that all generated files related to building just a particular area
>>>>> are removed.
>>>>> This was useful after I touched a header file.
>>>>> Now when I touch a header file, the new build system doesn't notice,
>>>>> so I have to manually purge, but nor does it (as far as I can see)
>>>>> give me
>>>>> a target to purge that component. To do this I need to go hunt down
>>>>> the directory with the object files and remove them.
>>>>> Is there something better I can do ?
>>>>>
>>>>> -phil.
>>>>>
>>>>
>>>> If you touch a header fie, the build is supposed to notice and "do
>>>> the right thing".
>>>>
>>>> -- Jon
>>>
>
More information about the build-dev
mailing list