Ernie, my comments were indeed very specific to the case at hand: the fix to the native binary for the Profiler Launch for Windows 64 bit and how to get that fix into the NetBeans distribution.
It just happens to be exactly the same challenge in the other cases I mention. I wrote my piece because I looked into if I could contribute for this specific problem (NETBEANS-1428, PR-2021). Let's recap: 1. Pedro's PR-2021 needs to be further reviewed and then - if approved - merged. 2. Then a new binary needs to be build for Windows 64 bit, the file profilerinterface.dll, based on the new Apache code, i.e. the code which was just merged. It is not as such difficult to build the new DLL locally, I can do it. Pedro has already done it (#1). No sweat. 3. The new binary then needs to become part of https://netbeans.osuosl.org/binaries/<hash>-profiler-external-binaries-8.2.zip (#2) in order to be picked up by the NetBeans build pipeline. However, we cannot just replace that single DLL in that ZIP because then the ZIP file would become a mix of CDDL licensed binaries and AL2 licensed binaries and from two different source code repos. Ouch!. So there's some complexity there. As a quick fix we want to avoid rebuilding for all those other platforms and only re-build for Windows, perhaps even only for Windows 64bit, right? We can maybe change the Java code for lib.profiler so that there's a external binaries ZIP for Windows and another for the rest of the platforms but that is a somewhat involved task and it adds complexity. Again, this specific design, the common ZIP, is shared with the other use cases I mention and the issue about integrating a new binary is exactly similar. This is why I struggle to see an easy quick fix for the problem at hand, integrating the new binary for the Profiler Launcher solely for Windows 64 bit. You very quickly end up in a situation where you need to rebuild binaries for MacOS and Linux too. I understand your frustration but I think this explains why people keep "hijacking" or digressing to the bigger picture as you mention and then the specific issue stalls. How annoying. The reason is it is just not that easy to see a path to a quick fix. From my analysis my conclusion is that we might as well tackle the bigger picture, i.e. creating an ASF build pipeline for those binaries. And I'm normally all for quick fixes :-) Peace. /Lars Ref #1: https://github.com/pedro-w/netbeans/releases/tag/v2 Ref #2: Currently https://netbeans.osuosl.org/binaries/45225DCFC94A9782419E95C70957822A0C44612D-profiler-external-binaries-8.2.zip as per the file https://github.com/apache/netbeans/blob/master/profiler/lib.profiler/external/binaries-list. On Wed, Jan 13, 2021 at 3:00 AM Ernie Rael <err...@raelity.com> wrote: > > This thread is about /Profiling on 64bit Windows/. With hopes to find a > short term solution; quick and dirty if nothing more general is available. > > This subject has been avoided for years often time by hijacking and > starting to talk about the big picture issue. Which of course is > important and includes important issues and information. Some of this > may have been in various discussions over the past years. (I don't know) > Maybe there's an issue open about it somewhere, where you could > contribute; or start a new thread. > > Where relevant, it would be great to reference those big picture here. > But not avoid the issue at hand. > > Apologies (and thanks for the space) for blowing off steam. > -ernie > > On 1/12/2021 12:13 AM, Lars Bruun-Hansen wrote: > > I think we as a community need to fix the "native builds" issue very > > soon. PRs are piling up. > > > > This current email thread is not the only one. Over the past 2 years > > fixes have been made (PRs merged) to native binaries code in the areas > > of > > > > * Native Launchers > > * NBI (installers) > > * Profiler launcher > > > > The problem is the same in all cases: The´source code is fixed but > > there's never a new binary being build hence nothing really happens. > > > > These binaries were never re-build in an Apache NetBeans setting. They > > were simply copied from their old Oracle-era location to > > https://netbeans.osuosl.org/binaries from where they are picked up by > > the Apache NetBeans build process but labelled as something which has > > a CDDL license. This is legally correct but is a limbo state: The > > source code is (now) owned by ASF but for reason of lack of time we > > are still using the pre-ASF binaries. I can 100% understand why such > > "shortcut" was made and salute those who made it happen. > > > > However, obviously it is sub-optimal that parts of the NetBeans > > Platform and IDE distribution effectively cannot be bug-fixed. > > > > The right solution IMHO is that those parts of the Apache NetBeans > > universe would be a first-class citizen in the general Jenkins build > > pipeline for the Platform and IDE distribution. By first-class I mean > > that the binary is automatically re-build whenever the source code > > changes. This would require Jenkins build slaves for Linux, MacOS and > > Windows (which I understand that ASF indeed has) and it would probably > > require quite a bit of setup work to get right. Apache NetBeans is a > > Java-oriented community so knowledge about building C/C++ binaries is > > limited which is probably why nobody so far is stepping forward. As > > Ernie suggests there may be a short term solution too which is more > > quick-and-dirty i.e. someone would re-build locally, verify the > > binaries and then upload as one-shot fix. However it is not always > > that simple. The binaries are distributed as one ZIP. If one decides > > to only re-build the binary for the Windows platform then this current > > packaging breaks down because then you have one binary in the ZIP > > which is ASF and the others which are CCDL and no longer build from > > the same revision in the VCS. It would be a mess. Therefore, in many > > ways, I'm not sure the quick-and-dirty solution really exists. > > > > Is this a correct status ? > > > > Lars > > > > > > > > > > > > > > > > On Tue, Jan 12, 2021 at 2:07 AM Eirik Bakke <eba...@ultorg.com> wrote: > >> Build issues aside, I think the code in the PR actually needs at least a > >> cursory review from someone else than the original author. Others, like > >> myself, have passed by and tested the fix or left other comments, but I'm > >> not sure anyone sat down and reviewed it all in one sitting. > >> > >> ( https://github.com/apache/netbeans/pull/2021 ) > >> > >> -- Eirik > >> > >> -----Original Message----- > >> From: Ernie Rael <err...@raelity.com> > >> Sent: Monday, January 11, 2021 12:34 PM > >> To: dev@netbeans.apache.org > >> Subject: Re: Profiling on 64bit Windows > >> > >> On 1/11/2021 6:53 AM, Geertjan Wielenga wrote: > >>> What needs to be done? Can you provide a PR? > >> Sadly no. I suspect that someone who knows their way around a distribution > >> would have that knowledge. I could be wrong, but I suspect it's simple. > >> > >> If it is simple and it hasn't been done in two years, I'd guess it's more > >> a lack of will or willingness to just check in the binaries. > >> > >> -ernie > >> > >> > >>> Gj > >>> > >>> On Mon, 11 Jan 2021 at 15:33, Ernie Rael <err...@raelity.com> wrote: > >>> > >>>> Hi all, > >>>> > >>>> There's been a fix for the 64 bit windows profiling problem for over > >>>> two years. > >>>> > >>>> https://github.com/pedro-w/netbeans/releases/tag/v0.1-alpha > >>>> https://issues.apache.org/jira/browse/NETBEANS-1428 > >>>> > >>>> AFAICT, it hasn't been integrated. There's some discussion every few > >>>> months or so on how to get the binaries to be automatically built as > >>>> part of the general build. An answer hasn't been found, so the > >>>> problem remains. These binaries have been around and in use for quite a > >>>> while. > >>>> > >>>> This issue seems stuck in the /Perfectionism is the enemy of > >>>> progress/ trap. > >>>> > >>>> Can't the binaries be checked in and included, while the > >>>> investigation for a solution proceeds? > >>>> > >>>> -ernie > >>>> > >>>> > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > >>>> For additional commands, e-mail: dev-h...@netbeans.apache.org > >>>> > >>>> For further information about the NetBeans mailing lists, visit: > >>>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > >>>> > >>>> > >>>> > >>>> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > >> For additional commands, e-mail: dev-h...@netbeans.apache.org > >> > >> For further information about the NetBeans mailing lists, visit: > >> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > >> > >> > >> > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > > For additional commands, e-mail: dev-h...@netbeans.apache.org > > > > For further information about the NetBeans mailing lists, visit: > > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > For additional commands, e-mail: dev-h...@netbeans.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org For additional commands, e-mail: dev-h...@netbeans.apache.org For further information about the NetBeans mailing lists, visit: https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
