RFR: Project files for Solaris Studio / NetBeans

[Volker Simonis]

On Mon, Mar 25, 2013 at 7:03 PM, Jesper Wilhelmsson <
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.


>
>
>> 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**> 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
>>>
>>