A couple of questions about the new build system

[Anthony Petrov]

You can't feed make with the /showInclude output. There's a dedicated 
tool in Cygwin (and on *NIX in general) - makedepend. It produces output 
that make can parse and understand directly.

--
best regards,
Anthony

On 4/8/2013 20:00, Kelly O'Hair wrote:
> 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
>