Volker Simonis skrev 25/3/13 8:59 PM:
On Mon, Mar 25, 2013 at 7:03 PM, Jesper Wilhelmsson
<[email protected] <mailto:[email protected]>> wrote:
Volker Simonis skrev 25/3/13 6:15 PM:
Hi Jesper,
first of all I highly welcome your initiative!
This is a joint initiative with Vladimir Voskresensky who works in the
Solaris Studio team.
Nevertheless I have some questions:
- Who will support these project files? As far as I can see, they will
have to be updated at least every time a file will be added, renamed
or deleted. Experience shows that such kind of project files tend to
get outdated very fast. Do you have any ideas how this problem can be
addressed?
One thing that was a pleasant surprise to me when I created the nbproject
was that if I add new source files, they are automatically brought into the
project. And when running make, the code assistant will be updated with the
new definitions in the new files. So even if the project file is slightly
out of date it will auto-update itself once you run make the first time.
I don't think I should volunteer to keep the project files up to date, but
since I will be using Solaris Studio for my daily work, and since I will be
notified about changes in the project files every time I run "hg status", it
seems pretty likely that I will push an updated project once in a while.
- At least for Mac.
- Where will other platform configurations go to? Will they be all
stored in "configurations.xml"
Yes, I think so.
- What about other configurations (i.e. DEBUG, PRODUCT, 32/64bit,
CC_INTERP, etc..)? Will they all have to go into the same
"configurations.xml"
If I'm not mistaken these are different make targets, right? I don't think
you need to have separate configurations saved in the project files for
different make targets. Vladimir can answer this much better, but the way I
have done it previously has simply been to edit the make command if I wanted
to build a different target, and the code assistant is automatically updated
when running make ("make clean" may be needed in some cases).
These are partially make targets but also preprocessor defines set by various
make targets. For example you may have different class definitions depending on
whether "DEBUG" is defined or not. Actually I don't understand how code
assistants is automatically updated if I do a "make clean" with a different make
target if I haven't defined the new preprocessor defines for the project. Is
this by parsing the generated libjvm.so? That's a neat feature of NetBeans but
as far as I know it only works if the VM is compiled with '-g3' which HotSpot
isn't by default.
In the current project all info about how the files are compiled are taken from
the make logs.
/Jesper
It seems that the "configurations.xml" might get quite big and complex
with all these configurations.
It's not too big right now IMHO. If it starts to grow unexpectedly in the
future I agree that we should reconsider the choice to store it in the
repository.
Thank you for your comments,
/Jesper
Thank you and best regards,
Volker
On Mon, Mar 25, 2013 at 5:29 PM, Jesper Wilhelmsson
<[email protected] <mailto:[email protected]>__>
wrote:
Hi,
Sorry for cross posting, but I think this could be useful for
several areas.
I would like to add Solaris Studio / NetBeans project files for the
entire
OpenJDK project. To clarify: One project that contains the entire
OpenJDK.
With the new build infrastructure in JDK 8 building the entire
OpenJDK is
fairly fast and even though I personally mostly work in the HotSpot
tree, I
tend to always clone and build the entire JDK forest. I find this to
have
several benefits.
Webrev: http://cr.openjdk.java.net/~__jwilhelm/7074926/webrev/
<http://cr.openjdk.java.net/~jwilhelm/7074926/webrev/>
The configuration in this project is currently Mac only. Linux and
Solaris
configurations are also planned.
The webrev is made from the jdk8/build repository which is where I
think a
change like this should go in. Let me know if you think something
else.
To use this project (once pushed):
1. Clone your favorite repository
hg clone http://hg.openjdk.java.net/__hsx/hotspot-gc
<http://hg.openjdk.java.net/hsx/hotspot-gc>
2. Get the whole forest
cd hotspot-gc
sh get_source.sh
3. Configure
sh configure
4. Open Solaris studio / NetBeans and load the project.
The project in located in the common directory.
Thanks,
/Jesper
