Re: A couple of questions about the new build system

[Erik Joelsson]

I tried it on solaris and found that it was broken there too. The output 
from the -xMMD compiler option that we use is not compatible with our 
makefiles. The object file is printed without directories, just the file 
name. Adding this to the bug.

/Erik
On 2013-04-08 19:10, Phil Race wrote:
FWIW, I was on Solaris 10 SPARC.

I sent you a separate email off-list since what I saw is that the case 
you
described does actually work but one that is different - in closed 
sources - didn't work.

-phil.

On 4/8/2013 9:00 AM, 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.joels...@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