search

apache / netbeans

Apache NetBeans
https://netbeans.apache.org/
Apache License 2.0
2.62k stars 840 forks source link

[NETBEANS-417] Updating Windows launchers binaries. #573

Closed jlahoda closed 6 years ago

jlahoda commented 6 years ago

General comments: -I've created new makefiles, as my primary development machine is Linux, it is set-up to do cross-compilation on Linux to produce the Windws binaries. This uses MinGW. The "old" makefiles are retained, we may do some more thorough cleanup later. -the launchers need to be built against jni.h; version from Apache Harmony appears to work OK, so include that one (it should be OK, I assume: it is an Apache source code) -the resulting binaries are marked to be under Apache License, which should be (hopefully) OK based on the "GCC RUNTIME LIBRARY EXCEPTION": https://gcc.gnu.org/onlinedocs/libstdc++/manual/license.html -testing by Windows users (esp. non-x86-64 users) greatly appreciated!

emilianbold commented 6 years ago

Is there some README file that could help me build this?

I also don't have Windows but could we perhaps create a Dockerfile to cross-compiles the Windows .exe?

Are the builds reproducible? Would I get the same binary / hashfile for the same .exe?

jlahoda commented 6 years ago

Sorry, no readme at this time. But not should not be really difficult to build that - on Ubuntu, IIRC I just installed the "mingw-w64" package (version 4.0.4-2), and the run the Makefile.mingw, e.g.: cd o.n.bootstrap/launcher/windows make -f Makefile.mingw

I myself probably won't have time to create (or probably even use) a Docker file, but anybody is free to do that.

I don't think the build is reproducible right now; -Wl,--no-insert-timestamp seems to make the exe build reproducible, but not the dll build.

emilianbold commented 6 years ago

I've managed to create app(64).exe using Docker, see https://github.com/emilianbold/incubator-netbeans/commit/96ce9f36cb1e104df0cb61c880272432912f527d

Sadly I had to tweak all those relative paths so the Docker context is smaller so I don't believe we can merge it as-is.

Why do we have the code scattered in so many folders?

I haven't added any reproducible build flags nor tested the binary on Windows yet (as I don't have any).

ebarboni commented 6 years ago

@jlahoda I try to build on windows. But it seems Makefile.mingw is not in the o.n.bootstrap/launcher/windows folder

apisupport.harness/windows-launcher-src/Makefile.mingw on my windows windres tools has not platform prefix

maybe generate with linux is better for now

jlahoda commented 6 years ago

Regarding the makefile in o.n.bootstrap/launcher/windows, oops. apparently I forgot to git add it - should be fixed now.

The (new) makefiles are not written (or intended) to be cross-platform. Given we need to recompile the launchers only rarely, I don't think we need a cross-platform build. I think it would be good to settle on a particular platform to do the build (which could be Windows, Linux or some kind of docker image), and do it using that approach. (The advantage of Linux (and docker probably too) is that it is easy to install/run on any other system in some kind of virtualization.)

Regarding sources organization, I think it makes some sense: o.n.bootstrap contains stuff that is platform (i.e. the base launcher); ide contains ide-specific launcher; and apisupport.harness the launcher for custom applications. (There is an unfortunate like from apisupport.harness to ide, which admittedly is a little weird, but otherwise seems to make sense in the modular world.)

ebarboni commented 6 years ago

I try a build on ubuntu on windows (wsl). Ubuntu 18.04, package mingw-w64.

Both w32 and w64 exe are generated.

Trying to launch give the following error (translated from french) unable to execute code, because libstc++-6.dll is not found.....

jlahoda commented 6 years ago

@ebarboni, thanks for testing (and I apologize for belated reply). Seems the build might have been missing some "-static" when building the exe files. I tried to improve that above - could you please try? (Given that it worked for me before, I assume I have a dynamic version of the library installed, so it is difficult for me to be certain if this helped or not, but the exe file is much bigger now, which seems like a good sign.)

Thanks!

emilianbold commented 6 years ago

Note we already had -static in apisupport.harness/windows-launcher-src. My Docker-built exe is ~800KB.

Regarding sources organization, I think it makes some sense: o.n.bootstrap contains stuff that is platform (i.e. the base launcher); ide contains ide-specific launcher; and apisupport.harness the launcher for custom applications. (There is an unfortunate like from apisupport.harness to ide, which admittedly is a little weird, but otherwise seems to make sense in the modular world.)

I understand the need for one 'generic' launcher and one 'ide' launcher (that perhaps searches for javac or whatever).

But why do we have 3 of them?

From what I remember we always had one exe to deal with when doing Platform apps and the only big challenge was changing the .exe icon.

jlahoda commented 6 years ago

The three launchers are: -platform base launcher -IDE launcher -launcher for platform applications

If the question is if we need separate IDE and application launchers, then there appear to be some differences between these, but I didn't study that in depth.

emilianbold commented 6 years ago

What does the "platform base launcher" do compared to "launcher for platform applications"?

jlahoda commented 6 years ago

As far as I can tell, the application launchers (either "netbeans" or "app" for the platform applications) compute things like userdir and cachedir locations, process etc/.conf and etc/.clusters, etc. The "app" launchers is I think as the "netbeans" launcher, just not referring to only "netbeans".

emilianbold commented 6 years ago

I guess it might have some (historical) reason... For me having an 'ide' launcher makes sense as perhaps we need to search for javac or something IDE-specific. A generic launcher for the bare platform or platform-apps would also make sense. The 3rd one... not so sure.

But I don't want to insist. The code looks good to me.

So, if somebody could test it on Windows we should be fine.

Note that I would still very much like to be able to build it with Docker. I need to tweak some things for a Docker build so it would be nice if we could rearrange things for Docker to work out of the box.

If you look at my patch https://github.com/emilianbold/incubator-netbeans/commit/96ce9f36cb1e104df0cb61c880272432912f527d , particularly build-with-docker.sh, I am first copying o.n.bootstrap/launcher/windows/ and ide/launcher/windows into the apisupport.harness/windows-launcher-src/ subtree so Docker doesn't have to swallow the whole NetBeans source tree.

Having these 3 launchers grouped differently might also make more sense. I wonder if we could use symbolic links inside git itself?

ebarboni commented 6 years ago

@jlahoda

this is for custom application based on Netbeans, apisupport.harness seems ok. I put it to bin folder it just tell that app.cluster is missing (this is expected) this is for Netbeans, ide seems ok too. I put it in place at netbeans / bin and netbeans launch with good jdk.

I have not idea for this one, this executable is located in platform/lib o.n.bootstrap/launcher/windows is missing "lib/nbexec.dll" at runtime. I guess the "lib/" must be removed on the -DNBEXEC_DLL parameters for nbexe64.exe and nbexec.exe to act as before

jlahoda commented 6 years ago

@ebarboni, thanks, you are right of course. I've updated the build scripts.

sdedic commented 6 years ago

@jlahoda, @emilianbold I am looing at the "app" launcher sources. It derives from "netbeans" launcher and sort of duplicates processing in "netbeans" launcher, but in places that interest me :-) it does not call super implementations, so ${DEFAULT_USERDIR_ROOT} etc placeholders are '''not''' replaced by "app" launcher - that's a bug I need to fix.

The "app" launcher adds processing of ${APPNAME} placeholder so that one .exe can serve for multiple platform-based application.

sdedic commented 6 years ago

After some thoughts ... are there some reasons why the "app" launcher diverges from the "netbeans" so much ? There also are some corner cases in NB's launcher which are not handled by "app" launcher. For example:

shouldn't we synchronize the launchers a bit ?

JaroslavTulach commented 6 years ago

The more processing can, @sdedic, be shared in nbexec, the better. The netbeans launcher is more advanced, as it was used more extensively - e.g. by a real product. The app.exe is just a demo toy, good for starting, but not sufficient for real production. The unsaid assumption was that once people need real launcher, they copy the source code and do what they want. There is however no reason for not enhancing the nbexec to work better for both netbeans as well as app.exe launches. If you can find the right abstractions, please go on and enhance nbexec.

sdedic commented 6 years ago

I think nbexec is fine as it is. For my current use-case it would be sufficient to better share code (inheritance) between app.exe and netbeans.exe. BUT that would probably require some changes in the config as well - it would become more similar to NB's .conf file (same replacements etc). If that is acceptable, I'll prepare the change.

sdedic commented 6 years ago

@jlahoda Could you rename ide/launcher/windows/Makefile.migw to Makefile.mingw ?

Otherwise the build process worked OK for me, tested on Windows 7.

jtulach commented 6 years ago

Please rebuild with changes from #683. Feel free to remove the AcceptLicense class then - it should be no longer needed.

sdedic commented 6 years ago

Filed https://issues.apache.org/jira/browse/NETBEANS-1145

sdedic commented 6 years ago

Folks, during addressing comments by @jtulach , I've found some dead code leftovers - cleaned up by commit 576b351. I think the review is still valid and will proceed with squash/merge.

eirikbakke commented 5 years ago

I added another pull request related to the Windows launchers, for HiDPI support, here: https://github.com/apache/incubator-netbeans/pull/883 . The launchers built fine on Windows/Ubuntu WSL, though I didn't include the binaries in the pull request--I assume there's a special process for that.

I noticed that the new launchers (netbeans64.exe and app64.exe) open up a new console when double-clicked in windows explorer. Might this be a recently introduced bug?

vikasprabhakar commented 5 years ago

@jlahoda @sdedic The following apache jira (Windows launcher fails to suppress console ) issue start from this PR (573) in Master branch. Please check the issues and provide your inputs on same.

  1. https://issues.apache.org/jira/browse/NETBEANS-1308
  2. https://issues.apache.org/jira/browse/NETBEANS-1436
eirikbakke commented 5 years ago

@vikasprabhakar Might those be fixed by https://github.com/apache/incubator-netbeans/pull/969 ? It doesn't seem like the latter has been applied yet. (At least NETBEANS-1308 should be fixed by the new launchers, but I haven't tested NETBEANS-1436.)