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).
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
<jesper.wilhelms...@oracle.com> 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/
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
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
