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