We have several platform specific tools defined that way already
(CYGPATH, MT, RC to name a few), so no worries. The error would be
trying to use them on the wrong platform, but protecting the assignment
won't help with that.
/Erik
On 2014-05-21 18:33, David DeHaven wrote:
As long as XCODEBU
On 2014-05-22 02:49, Omair Majid wrote:
* Andrew Hughes [2014-05-21 20:23]:
- Original Message -
* Andrew Hughes [2014-05-21 12:22]:
I'm not keen on the hardcoding of '-ljpeg'
+ LIBJPEG_LIBS := -ljpeg
There's no pkg-config files for it. Any suggestions on how to get
something gen
Good point.
I'm also wondering, what if (for whatever reason) MACOSX_SDK_PATH is empty?
That will cause the -isysroot argument to be invalid. I can either make an
undefined MACOSX_SDK_PATH a hard error (in configure) or I can wrap all uses of
-isysroot/-iframework with ifneq blocks. Personally
On May 22 2014, at 09:14 , David DeHaven wrote:
>
> Good point.
>
> I'm also wondering, what if (for whatever reason) MACOSX_SDK_PATH is empty?
>
> That will cause the -isysroot argument to be invalid. I can either make an
> undefined MACOSX_SDK_PATH a hard error (in configure)
Earlier fail
>> That will cause the -isysroot argument to be invalid. I can either make an
>> undefined MACOSX_SDK_PATH a hard error (in configure)
>
> Earlier failure is better.
>
>> or I can wrap all uses of -isysroot/-iframework with ifneq blocks.
>
> Yuck.
Agreed. I already don't like that I have to u
BTW .. I just realised I haven't seen a bug ID in this thread.
Does one already exist ?
-phil.
On 5/21/14 5:49 PM, Omair Majid wrote:
* Andrew Hughes [2014-05-21 20:23]:
- Original Message -
* Andrew Hughes [2014-05-21 12:22]:
I'm not keen on the hardcoding of '-ljpeg'
+ LIBJPEG_
- Original Message -
>
> On 2014-05-22 02:49, Omair Majid wrote:
> > * Andrew Hughes [2014-05-21 20:23]:
> >> - Original Message -
> >>> * Andrew Hughes [2014-05-21 12:22]:
> I'm not keen on the hardcoding of '-ljpeg'
>
> + LIBJPEG_LIBS := -ljpeg
> >>> There's n
Please review the following change, destined for jdk7u-dev. The zip
implementation in unpack200 depends on _BIG_ENDIAN being defined on big
endian platforms, and the define is missing on the linux/sparc platform(s).
Note that in the new build system (jdk8+) the relevant logic was
rewritten,
* Phil Race [2014-05-22 16:02]:
> BTW .. I just realised I haven't seen a bug ID in this thread.
> Does one already exist ?
No. I was going to create one before I push.
Thanks,
Omair
--
PGP Key: 66484681 (http://pgp.mit.edu/)
Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681
Looks good but IIRC PPC also needs this.
Kumar
On 5/22/2014 1:13 PM, Mikael Vidstedt wrote:
Please review the following change, destined for jdk7u-dev. The zip
implementation in unpack200 depends on _BIG_ENDIAN being defined on
big endian platforms, and the define is missing on the linux/spa
AFAICT PPC already has the define:
199 CFLAGS_REQUIRED_ppc += -fsigned-char -D_BIG_ENDIAN
Cheers,
Mikael
On 2014-05-22 13:31, Kumar Srinivasan wrote:
Looks good but IIRC PPC also needs this.
Kumar
On 5/22/2014 1:13 PM, Mikael Vidstedt wrote:
Please review the following change, destin
I think that it would be useful to have a bug id prior to sending a
review request, so that a review thread for the bug can be easily found
in the mailing archive. In the future, please do file a bug first and
put its id in the subject line of your review requests.
--
best regards,
Anthony
On
* Anthony Petrov [2014-05-22 16:48]:
> I think that it would be useful to have a bug id prior to sending a review
> request, so that a review thread for the bug can be easily found in the
> mailing archive. In the future, please do file a bug first and put its id in
> the subject line of your revi
Thanks, Omair.
--
best regards,
Anthony
On 5/23/2014 1:01 AM, Omair Majid wrote:
* Anthony Petrov [2014-05-22 16:48]:
I think that it would be useful to have a bug id prior to sending a review
request, so that a review thread for the bug can be easily found in the
mailing archive. In the futu
Looks good.
David
On 23/05/2014 6:13 AM, Mikael Vidstedt wrote:
Please review the following change, destined for jdk7u-dev. The zip
implementation in unpack200 depends on _BIG_ENDIAN being defined on big
endian platforms, and the define is missing on the linux/sparc platform(s).
Note that in
Build systems take such a long time work on...
I've changed the logic, I think for the better. I hijacked --with-sysroot,
SYSROOT is set to the SDK path and I stuffed the -iframework argument alongside
the -isysroot arg in SYSROOT_CFLAGS and it works very nicely. Now the only
change that's pep
16 matches
Mail list logo
