Closed jlahoda closed 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?
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.
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).
@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
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.)
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.....
@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!
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.
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.
What does the "platform base launcher" do compared to "launcher for platform applications"?
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/
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?
@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
@ebarboni, thanks, you are right of course. I've updated the build scripts.
@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.
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:
HOME
token has different meaning on Windows and *NIX: on Windows, $HOME is replaced by AppData
or LocalAppData
; on UNIXes, HOME is ... well ;) home. The "netbeans" launcher uses the same (CSIDL_DESKTOP) for both cases.DEFAULT_USERDIR_ROOT
is not procssed by "app" launcher, which invokes nbexec.dll without --default_userdir_root
. This may cause issues if an upgrade mechanism similar to NetBeans is used (I do in my app).--clusters
? @JaroslavTulach - is it OK ?shouldn't we synchronize the launchers a bit ?
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
.
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.
@jlahoda Could you rename ide/launcher/windows/Makefile.migw
to Makefile.mingw
?
Otherwise the build process worked OK for me, tested on Windows 7.
Please rebuild with changes from #683. Feel free to remove the AcceptLicense
class then - it should be no longer needed.
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.
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?
@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.
@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.)
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!