Re: RFR: JDK-8195689 Remove generated-configure.sh and instead use autoconf

[Martin Buchholz]

Alright folks, you've convinced me.

The "builder interface" is the same "bash configure && make"
(aside: having configure be non-executable is super-annoying, because it
changes an interface burned into my fingers)
and yes, users already have to install many dependencies.
I was thinking you would force users to run some other command like
autoconf; that was the path I recall taken by some other projects.

On debian-based systems, there's "sudo apt-get build-dep openjdk-N" for
some N close to whatever you're actually building.



On Thu, Jan 18, 2018 at 11:49 PM, Magnus Ihse Bursie <
magnus.ihse.bur...@oracle.com> wrote:

> On 2018-01-19 08:08, Erik Helin wrote:
>
>> On 01/19/2018 07:18 AM, Martin Buchholz wrote:
>>
>>> Differing projects have come to different conclusions about whether to
>>> include a generated configure.
>>>
>>> But the standard seems to be to include one. The mantra is: "./configure
>>> &&
>>> make" without an autoconf step.
>>>
>>
>> And this is still the mantra (except we don't have an executable
>> configure file in the repo so you have to run `bash configure && make`).
>> The only thing we are discussing is whether the script "configure" should
>> depend on the program "autoconf" or not.
>>
>> If I'm downloading a .tar.gz source code bundle of a project (like the
>> ones usually generated via `make dist`), then it seems more common that
>> "configure" will not depend on autoconf. However, if I'm cloning a project
>> from source, then I'm used to having autoconf being run for me (or
>> sometimes having to run it myself).
>>
> Good point. If we were to start shipping source code bundles, it would
> certainly make sense to include a generated configure script for it. I'm
> all for it. The problem here is that the current model presupposes a
> working, generated configure script for every separate commit.
>
> I'll admit that I was part of introducing this model some five (or more?)
> years ago. I didn't really like it then either, but at that time I
> perceived it to be a quite massive resistance amongst the JDK developers
> (perhaps mostly inside Oracle) for any kind of change in the environment,
> so adding a new build requirement seemed like a huge war that was needed to
> be fought. (Just removing the old build system was enough effort...)
> Nowadays, we're using jib inside Oracle, so a new requirement is virtually
> undetectable by most developers. And for all others, it's just an "sudo apt
> install autoconf" (or brew, or whatever) away, in the unlikely case that
> you're a developer without autoconf installed already.
>
> /Magnus
>
>
>> The number of people building openjdk is
>>> much larger than the number of people patching configure.  So I agree
>>> with
>>> David that we should stick with the status quo.
>>>
>>
>> I disagree, I don't think depending on autoconf will make it harder to
>> build OpenJDK. Remember that the build steps are still:
>>
>> $ bash configure
>> $ make
>>
>> the only difference now is that configure will use autoconf to first
>> generate .build/generated-configure.sh. As noted in the documentation,
>> installing autoconf is trivial on essentially any system today (the
>> configure script will also provide a useful help message for your platform
>> if you are missing autoconf).
>>
>> So for me, this patch gets +1. I'll leave the actual Makefile changes and
>> details for Erik J to review though ;)
>>
>> Thanks,
>> Erik
>>
>> On Thu, Jan 18, 2018 at 6:14 PM, David Holmes 
>>> wrote:
>>>
>>> On 18/01/2018 11:28 PM, Magnus Ihse Bursie wrote:

 Currently, we require all developers who modify the configure script to
> run autoconf locally, to update the generated-configure.sh script,
> which is
> then checked in. This is the only instance of checked in "compiled"
> code in
> OpenJDK, and this has brought along several problems:
>
> * Only a specific version of autoconf, 2.69, can be used, to avoid
> large
> code changes in the generated file. Unfortunately, Ubuntu ships a
> version
> of autoconf that claims to be 2.69 but is actually heavily patched.
> This
> requires all Ubuntu users to compiler their own autoconf from source.
>
> * The Oracle JDK closed sources has a closed version that needs to be
> updated. In practice, this has meant that all non-Oracle developers,
> need
> an Oracle sponsor for patches modifying the configure script.
>
> * If the configure script is not properly updated, the build will fail.
> The same happens on the Oracle side if the closed version is not in
> sync
> with the open version. It is easy to miss re-generating the script
> after
> the last fix of a typo in the comments in an .m4 file...
>
> * Merging between two changes containing configure modifications is
> almost impossible. In practice, the entire generated-configure.sh
> needs to
> be thrown away and regenerated.

Re: OpenJDK installation instructions - SUSE install instructions are missing

[Martin Buchholz]

On Fri, Jan 19, 2018 at 11:16 AM, John Paul Adrian Glaubitz <
glaub...@physik.fu-berlin.de> wrote:

> On 01/19/2018 07:43 PM, Martin Buchholz wrote:
> > [+build-dev]
>
> Does this really fit here? It's not related to building OpenJDK but
> rather just installing, isn't it?
>

Oh, I think you're right!  Although there's a big overlap between those
expert at building and those expert at installing.


>
> FWIW, the installation instructions for Debian are also outdated as
> they are missing OpenJDK-9 which can now be installed through Debian
> Backports.
>
> Adrian
>
> --
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer - glaub...@debian.org
> `. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
>   `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>

Re: OpenJDK installation instructions - SUSE install instructions are missing

[John Paul Adrian Glaubitz]

On 01/19/2018 07:43 PM, Martin Buchholz wrote:
> [+build-dev]

Does this really fit here? It's not related to building OpenJDK but
rather just installing, isn't it?

FWIW, the installation instructions for Debian are also outdated as
they are missing OpenJDK-9 which can now be installed through Debian
Backports.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: OpenJDK installation instructions - SUSE install instructions are missing

[Martin Buchholz]

[+build-dev]

On Fri, Jan 19, 2018 at 9:48 AM, Stefan Knorr  wrote:

> Hi,
>
> I noticed that the page at http://openjdk.java.net/install/ does not
> mention how to install OpenJDK on SUSE-based distros (openSUSE and SUSE
> Linux Enterprise/SLE). Would it be possible to add that information?
>
> For the record, the package name is the same as on Fedora, but the
> command to install is different:
>
> sudo zypper in java-1_8_0-openjdk
>
>
> Please keep me on CC for responses, I am not subscribed to this list.
>
>
> Thanks in advance,
>
> Stefan.
>
>
> (Btw, the Fedora instructions seem a bit outdated too -- iirc, Fedora
> now uses dnf as its main package manager.)
>
> --
> SUSE Linux GmbH. Geschäftsführer: Felix Imendörffer, Jane Smithard,.
> Graham Norton. HRB 21284 (AG Nürnberg).
>
>

Contribute towards native code which override to OpenJDK

[Archana Nogriya]

Hi, 

Why this contribution is required

These changes are to support the override of native C/C++ source by the 
SetupNativeCompilation macro in a similar way to how java classes can be 
overridden in SetupJavaCompilation. This will enable extension/closed 
source providers to easily override native implementations.

Changes were made in:

make/common/NativeCompilation.gmk
diff -r 3a52333a5e57 make/common/NativeCompilation.gmk
--- a/make/common/NativeCompilation.gmk Tue Jan 02 16:35:04 2018 -0500
+++ b/make/common/NativeCompilation.gmk Tue Jan 16 13:42:54 2018 +
@@ -511,8 +511,14 @@
   $$(error SRC specified to SetupNativeCompilation $1 contains 
missing directory $$d)))
 
   # Find all files in the source trees. Preserve order.
-  $1_SRCS := $$(foreach s, $$($1_SRC), $$(call CacheFind,$$(s)))
+  $1_SRCS := $$(call uniq, $$(foreach s, $$($1_SRC), $$(call 
CacheFind,$$(s
   $1_SRCS := $$(filter $$(NATIVE_SOURCE_EXTENSIONS), $$($1_SRCS))
+  $1_SRCS := $$(strip $$(foreach s, $$($1_SRCS), \
+   $$(eval relative_src := $$(call remove-prefixes, $$($1_SRC), 
$$(s))) \
+$$(if $$($1_$$(relative_src)), \
+  $$(eval $1_NATIVE_EXCLUDE_FILES += $$(s)), \
+  $$(eval $1_$$(relative_src) := 1) $$(s
+  $1_SRCS := $$(filter-out $$($1_NATIVE_EXCLUDE_FILES), $$($1_SRCS))
   # Extract the C/C++ files.
   ifneq ($$($1_EXCLUDE_PATTERNS), )
 # We must not match the exclude pattern against the src root(s).



This new code has been tested by building with latest JDK11. Build has 
been successful. 
Please let me know what is your view on these changes and if we can 
contribute to openJDK. 


Thanks and Regards
Archana Nogriya 
IBM Java Runtime, Open Java Developer
IBM Hursley
Tel: Internal - 247073, External - +44 (0) 1962 81 7073
Office Mobile: 07500095480
Email: archana.nogr...@uk.ibm.com
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU