RFR: Project files for Solaris Studio / NetBeans

Jesper Wilhelmsson jesper.wilhelmsson at oracle.com
Mon Mar 25 20:11:28 UTC 2013


Volker Simonis skrev 25/3/13 8:59 PM:
>
>
> On Mon, Mar 25, 2013 at 7:03 PM, Jesper Wilhelmsson
> <jesper.wilhelmsson at oracle.com <mailto:jesper.wilhelmsson at oracle.com>> 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
>         <jesper.wilhelmsson at oracle.com <mailto:jesper.wilhelmsson at 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/
>             <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
>
>



More information about the core-libs-dev mailing list