Volker Simonis skrev 25/3/13 8:59 PM:


On Mon, Mar 25, 2013 at 7:03 PM, Jesper Wilhelmsson
<jesper.wilhelms...@oracle.com <mailto:jesper.wilhelms...@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.wilhelms...@oracle.com <mailto: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/
            <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


Reply via email to