Problems with ALT_OUTPUTDIR in debug build
Kelly O'Hair
Kelly.Ohair at Sun.COM
Fri Jan 11 16:42:05 UTC 2008
Sigh... These short names (what did you call them 8.3? what is that?) on windows only
make sense on directories that exist and never get deleted, like the install location
of the C++ compiler etc. They just don't work well with directories that are being created
or deleted and re-created.
I think what needs to happen for the default OUTPUTDIR is to just get the short path of the
source tree, then add the "/build/..." to construct _OUTPUTDIR (the default).
That way if the OUTPUTDIR gets removed and recreated, this short path is still valid.
And if an ALT_OUTPUTDIR is provided, assume it's a path with no whitespace and just use
it literally as is, maybe verify the path has no spaces in it as a sanity check?
Is it acceptable to assume that any ALT_OUTPUTDIR setting is a path without spaces?
-kto
Ted Neward wrote:
>> You wrote that the "MKDIRs" in the setup rules are only needed to
>> workaround a windows problem. I didn't built an Windows, but perhaps
>> somebody can try if they are still needed (Ted?). And if they will be
>> really needed, perhaps we can conditionally enable them on Windows
>> only, so we don't clutter the Unix build with usless directories?
>>
> Right now I'm still stuck trying to get the Windows build to work from the top-level makefile; I'm waiting for bNext to try again and verify if it's an environment issue or a source/make issue, so I can't say for certain. But, IIRC, the last time I looked, the situation on Windows is worse, because we get not only the four directories you mention, but 8.3-named versions of them, as well, so (from memory) you'd end up with:
>
> build
> build-debug
> build-fastdebug
> build-d?1
> build-f?1
>
> where the last two are the 8.3 versions of the longer filenames, and they're all empty.
>
> Ted Neward
> Java, .NET, XML Services
> Consulting, Teaching, Speaking, Writing
> http://www.tedneward.com
>
>
>> -----Original Message-----
>> From: Volker Simonis [mailto:volker.simonis at gmail.com]
>> Sent: Friday, January 11, 2008 1:05 AM
>> To: Kelly O'Hair
>> Cc: build-dev at openjdk.java.net; Ted Neward
>> Subject: Re: Problems with ALT_OUTPUTDIR in debug build
>>
>> Ok, I think I can live with ALT_OUTPUTDIR=$(OUTPUTDIR)-$(DEBUG_NAME)
>> as well. This at least honours the original user setting of
>> ALT_OUTPUTDIR (though with a "-debug" suffix).
>>
>> But it will create FOUR outputdirectories, if we say "make debug_build
>> ALT_OUTPUTDIR=xxx" of which only "xxx-debug" will be used:
>>
>> xxx
>> xxx-debug
>> xxx-debug-fastdebug
>> xxx-fastdebug
>>
>> If we say "make fastdebug_build ALT_OUTPUTDIR=xxx" if will create
>> THREE directories, of which only "xxx-fastdebug", will be used:
>>
>> xxx
>> xxx-fastdebug
>> xxx-fastdebug-fastdebug
>>
>> I still think this is quite confusing (especially
>> "xxx-debug-fastdebug" and "xxx-fastdebug-fastdebug" - what should they
>> be good for).
>>
>> The main cause for this hassle is the setup rule in the top-level
>> Makefile (and the recursive invocation of this makefile for the
>> "debug" and "fasdebug" targets) :
>>
>> setup:
>> $(MKDIR) -p $(OUTPUTDIR)/j2sdk-image
>> $(MKDIR) -p $(ABS_OUTPUTDIR)/j2sdk-image
>> $(MKDIR) -p $(OUTPUTDIR)-fastdebug/j2sdk-image
>> $(MKDIR) -p $(ABS_OUTPUTDIR)-fastdebug/j2sdk-image
>>
>> I still don't understand why it is necessary, because if I remove all
>> the MKDIRs, (and with ALT_OUTPUTDIR=$(OUTPUTDIR)-$(DEBUG_NAME) as
>> suggested above), at least on my Linux box everything works fine:
>>
>> "make debug_build ALT_OUTPUTDIR=xxx" creates two directories and puts
>> the output to "xxx-debug":
>>
>> xxx
>> xxx-debug
>>
>> "make fastdebug_build ALT_OUTPUTDIR=xxx" creates two directories and
>> puts the output to "xxx-fastdebug":
>>
>> xxx
>> xxx-fastdebug
>>
>> and "make all ALT_OUTPUTDIR=xxx" creates just "xxx" and puts the
>> output into.
>>
>> This seams reasonable to me!
>>
>> You wrote that the "MKDIRs" in the setup rules are only needed to
>> workaround a windows problem. I didn't built an Windows, but perhaps
>> somebody can try if they are still needed (Ted?). And if they will be
>> really needed, perhaps we can conditionally enable them on Windows
>> only, so we don't clutter the Unix build with usless directories?
>>
>> Regards,
>> Volker
>>
>> On 1/10/08, Kelly O'Hair <Kelly.Ohair at sun.com> wrote:
>>> ALT_OUTPUTDIR=$(OUTPUTDIR)
>>> doesn't make sense to me.
>>>
>>> The makefiles will define OUTPUTDIR to be equal to $(ALT_OUTPUTDIR)
>> if
>>> ALT_OUTPUTDIR is set.
>>> The _OUTPUTDIR is the default build location, when ALT_OUTPUTDIR is
>> not set.
>>> The original idea here in setting ALT_OUTPUTDIR=$(_OUTPUTDIR)-
>> $(DEBUG_NAME)
>>> was to put all the results of a debug build in a completely different
>>> directory, which I still think is right.
>>> I suspect this needs to be:
>>> ALT_OUTPUTDIR=$(OUTPUTDIR)-$(DEBUG_NAME)
>>>
>>> A long time ago, the debug files were built along side the normal
>> files, and
>>> all debug files had that "_g" suffix (e.g. jvm_g.dll, etc.) but we
>> completely
>>> got rid of that because it was a nightmare.
>>> The debug builds then just became a second pass over the source with
>> the same
>>> makefiles but just a different output directory so they didn't mix.
>>> I'm afraid using ALT_OUTPUTDIR=$(OUTPUTDIR) will mix up the optimized
>> files
>>> with the debug files, which won't be good.
>>>
>>> -kto
>>>
>>> Volker Simonis wrote:
>>>> I would suggest to fix the top-level Makefile such that
>>>> COMMON_DEBUG_FLAGS uses $(OUTPUTDIR) instead of $(_OUTPUTDIR)
>>>> and doesn't append "-$(DEBUG_NAME)" to ALT_OUTPUTDIR like so:
>>>>
>>>> COMMON_DEBUG_FLAGS= \
>>>> DEBUG_NAME=$(DEBUG_NAME) \
>>>> ALT_OUTPUTDIR=$(OUTPUTDIR) \
>>>> NO_DOCS=true
>>>>
>>>> We will than always end up with two directories like so:
>>>>
>>>> xxx
>>>> xxx-fastdebug
>>>>
>>>> if we used "ALT_OUTPUTDIR=xxx".
>>>>
>>>> "xxx-fastdebug" will always be empty (but needed if I follow your
>>>> previous post) so we can remove it after the build. But the user
>> will
>>>> get the output in the directory he specified with ALT_OUTPUTDIR and
>>>> that seems crucial to me.
>>>>
>>>> What do you think?
>>>>
>>>> Volker
>>>>
>>>> On 1/10/08, Kelly O'Hair <Kelly.Ohair at sun.com> wrote:
>>>>> Your final paragraph I think is the answer:
>>>>>
>>>>> "In my eyes, the cleanest solution would be if ALT_OUTPUTDIR
>> would be honoured
>>>>> "as is", as the output directory for everything we built,
>> without anything
>>>>> appended to it. So the developer should be free to choose
>> whatever he wants as
>>>>> the output directory. And there should be no additional
>> directories created."
>>>>> The ongoing problem has been how to make this work in all cases.
>>>>> But I'm all for it.
>>>>>
>>>>> The generally accepted default for an output directory has been a
>> ./build or
>>>>> ./dist directory at the top of the source tree you are building.
>>>>> With corba, jaxp, jaxws, langtools, hotspot all being
>> independently buildable,
>>>>> what exactly are you recommending to fix this?
>>>>>
>>>>> -kto
>>>>>
>>>>> Volker Simonis wrote:
>>>>>>>> Any comments if this is the right way to do a debug build?
>>>>>>> If it works it's fine. I usually just run 'make debug_build',
>> does that not work?
>>>>>> It works, but it has the problems that I detailed in my first
>> mail.
>>>>>> Did you also read that one?
>>>>>> I may seem that my second mail contained the solution for the
>> first
>>>>>> one, but that's not true, its justa partial workaround for the
>> problem
>>>>>> described in the first one:
>>>>>>
>>>>>> http://mail.openjdk.java.net/pipermail/build-dev/2008-
>> January/000669.html
>>>>>> Thanks and regards,
>>>>>> Volker
>> No virus found in this incoming message.
>> Checked by AVG Free Edition.
>> Version: 7.5.516 / Virus Database: 269.19.0/1218 - Release Date:
>> 1/10/2008 1:32 PM
>>
>
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.5.516 / Virus Database: 269.19.0/1218 - Release Date: 1/10/2008 1:32 PM
>
>
More information about the build-dev
mailing list