[oe] [meta-java][PATCH 1/2] classes:java: move version_specific_cflags to java.bbclass
André Draszik
git at andred.net
Wed Aug 8 09:00:23 UTC 2018
Hi,
On Mon, 2018-08-06 at 08:31 +0200, Richard Leitner wrote:
> On 08/04/2018 11:53 AM, André Draszik wrote:
> > On Thu, 2018-08-02 at 16:45 +0200, Andreas Obergschwandtner wrote:
> > > moved version_specific_cflags from openjfdk-8-common.inc to
> > > java.bbclass
> > > and
> > > renamed it to java_version_specific_cflags because it will be used for
> > > a
> > > fix
> > > in icedtea7
> >
> > Does it really make sense to have openjdk / icedtea specific flags in a
> > generic java class in a function with a generic name as is
> > java_version_specific_cflags?
>
> As far as I understood this patch the specific GCC flags are in the
> openjdk/icedtea recipe (those FLAGS_GCCx which are appended to C(XX)FLAGS
> using the java_version_specific_cflags function).
>
> Therefore I think the function itself is not bound to any recipe at all as
> it only checks if the flags should be set for the used GCC version.
>
> Nonetheless a improvement which would make sense IMHO is:
> a) either getting the fact it's for GCC-only inside the function name or
> make it work for all supported compilers
> b) maybe move it to oe-core or meta-oe as it might be useful also for
> other recipes (beside java).
>
> What do you think about it?
OK, fair enough, the commit message subject is mentioning
version_specific_cflags, and I didn't read the actual patch carefully
enough.
Still, this patch places things related to *compiling* Java itself into a
class (java.bbclass) that is meant to be used by recipes building/installing
java sources judging by the class' name.
> Maybe it would be better to create a new class for these things instead?
>
> As mentioned above, I don't think it is openjdk/icedtea specific...
> Basically it's not even java specific. IMHO it's a plain helper function
> for GCC flags which are not supported in older releases of GCC. So maybe
> there's really a better place to be in for this function. Any ideas?
In this specific case, it's a patch against master, and it's for GCC >= 6.
Are compilers not supporting -fno-lifetime-dse -fno-delete-null-pointer-
checks (gcc 5?) even still supported by everything on master? Would it make
sense to add -fno-lifetime-dse -fno-delete-null-pointer-checks to CFLAGS
CXXFLAGS unconditionally instead?
Cheers,
Andre'
More information about the Openembedded-devel
mailing list