[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