I've developed a python script for building a bunch of dependencies that I need for my project. Among them is Poco.
On OS X and Linux I'm using cmake to build Poco and my first thought was to do the same for Windows. It seems, however, that the cmake pipeline isn't supported on Windows (or I'm doing something wrong) which leads me to my question; how do I go about building Poco for windows from the commandline?
For Windows you will find preconfigured scrips for building POCO using specific VS compiler version i.e. build_vs120.cmd or generic one buildwin.cmd which you can configure according to what you need:
C:\dev\workspace\poco-1.6.0>buildwin.cmd
Usage:
------
buildwin VS_VERSION [ACTION] [LINKMODE] [CONFIGURATION] [PLATFORM] [SAMPLES] [TESTS] [TOOL]
VS_VERSION: "90|100|110|120"
ACTION: "build|rebuild|clean"
LINKMODE: "static_mt|static_md|shared|all"
CONFIGURATION: "release|debug|both"
PLATFORM: "Win32|x64|WinCE|WEC2013"
SAMPLES: "samples|nosamples"
TESTS: "tests|notests"
TOOL: "devenv|vcexpress|wdexpress|msbuild"
Default is build all.
NOTE: You may need to download sources for Windows
Edit: There doesn't seem to be an install equivalent on Windows for when using the build batch script. In order to mimic linux install, one needs to merge all include folders into one, so basically copy include folders from Foundation, JSON, Net, Util, XML, and so on into one location by overwriting them. All folders except Foundation which is a Poco core namespace have structure: {Name}/include/Poco/{Name}, i.e. Util/include/Poco/Util so they will merge without any problem. As a result one should get the following structure: include/Poco/* This should be easy to scriptize too.
Related
Please note: I have created this GitHub project right here that can be used to perfectly reproduce the problem I'm seeing.
Java 8 here attempting to use Launch4J via the gradle-launch4j Gradle plugin to build a Windows native EXE application. I am doing the development of a Java Swing app on my Mac but the app must run as a Windows EXE on Windows 10. I am also using ShadowJar to build my self-contained "fat jar".
I can build my (Swing) app's fat jar and then run it on my Mac via java -jar build/lib/myapp.jar. It starts and runs no problem.
Here is my Gradle config for Launch4J:
launch4j {
mainClassName = 'com.example.windows.hello.HelloWindowsApp'
icon = "${projectDir}/icon.ico"
jdkPreference = 'jdkOnly'
initialHeapSize = 128
jreMinVersion = '1.8.0'
jreMaxVersion = '1.8.9'
maxHeapSize = 512
stayAlive = false
bundledJre64Bit = true
bundledJrePath = '../hello-windows/jre8'
}
When I run ./gradle clean build shadowJar createExe createDistro it produces:
hello-windows.zip/
hello-windows.exe --> The Windows EXE built by the 'createExe' task
lib/* --> The lib/ dir for the EXE that is also built by the `createExe` task
jre8/ --> OpenJDK JRE8 (copied from the libs/jre8 dir)
So I copy that ZIP file and port it over to a Windows 10 (64-bit) machine. I extract the ZIP and run the EXE by double clicking it inside Windows Explorer (which I can confirm does see the EXE as an Application type). First I see this:
Why is this happening? Are there any Launch4J configurations/settings I can change so that this doesn't happen?
Thanks in advance!
You need to sign the executable created by launch4j as described here to prevent SmartScreen from blocking it to be run. See also the related discussion in the support forum.
Your first question is more like a Windows question. When you unzip an application from a zip file, Windows will naturally mark it as unsafe, in fact if you check the application properties tab, you will see a checkbox where you can remove that unsafe attribute. It's same as running chmod+x for an executable script in Linux.
For the second part, I assume you are using the gradle plugin for Launch4j, there are two main ways to configure Launch4j assuming your project folder is structured commonly with the jre library in the same folder containing your executable folder.
By specifying the path only like
../jre
By specifying the full relative path
../jre/bin/javaw.exe
Your generated xml at the end should look like this in the first case.
<jre>
<path>../jre</path>
</jre>
The main point is that the path to JRE is relative to the position of the executable not the current directory. In this case, we step back one directory from the executable folder to the folder containing jre.
Try setting the bundledJrePath in your build.gradle to just jre8:
launch4j {
...
bundledJrePath = 'jre8'
}
Because that is in your case the relative path where the jre is when extracting the zip.
http://launch4j.sourceforge.net/docs.html
<path>, <minVersion>, <maxVersion>
The <path> property is used to specify the absolute or relative path (to the executable) of a bundled JRE, it does not rely on the current directory or <chdir>. Note that this path is not checked until the actual application execution
Beware that the path must not contain the /bin/javaw.exe.
When running the exe with the debug flag like this
hello-windows.exe --l4j-debug
then it will create a file launch4j.log in the same directory.
There you can check that the correct jre is picked up, for example:
...
Bundled JRE: jre8
Check launcher: C:\Users\IEUser\Downloads\hello-windows\jre8\bin\javaw.exe (OK)
...
I upvoted the answer above from sschuberth, as that is the best answer to your question. Signing the executable will make SmartScreen happy.
As addition I would rather prevent trying to create an executable, even signing it, best to create a MSI. For example by using Javapackager. See also this question. That guy created his own tool after using Nullsoft.
It is very cumbersome to get an executable accepted by every virus scanner around the world. I have the experience of using WIX Toolset to create an MSI and wrapped it into a bootstrapper executable, signed it using the company signing certificate. However in the end I had to send requests to McAfee, Norton, Avast, AVG, KasperSky and Trend Micro. Gladly all accepted it over time, only Trend Micro never even responded.
I have a tool, call it mytool, that makes use of other code in a separate package I have written - call it mypackage.
I can build and test it in LiteIDE if I use the following structure:
/src/mypackage/mypackage.go
/src/mytool/tool.go
/src/mytool/tool.yaml
but when I want to test or deploy on GAE using:
cd ... \src\
\go\gae\go_appengine\dev_appserver.py mytool/
or
\go\gae\go_appengine\appcfg.py update mytool/
I have to move stuff around to:
/src/mytool/mypackage/mypackage.go
/src/mytool/tool.go
/src/mytool/tool.yaml
Is there something I can change in LteIDE so it can handle the second structure or is there something I can change in the GAE setup to make it handle the first structure?
I am working on Windows 7.
Have you tried installing the package using go install? That creates the compiled binary in the packages directory so the rest of your packages/code can treat it the same as a 3rd-party package.
utoday I got the task to integrate a floating license server for install4j to our build process. Therefore I read the README.txt and the following two threads:
install4jc-specifying-floating-server and floating-license-setup-on-a-headless-ubuntu-server
Now there are still some questions left. Therefore I will describe our build environment shortly. We are using maven to build our software and installer and startet to test install4j by using the maven-plugin for install4j:
We installed the install4j application as zip file to our maven repository
during maven build we download and extract this file to some target directory
until now we installed the demo-license via maven-plugin to the install4j folder
during the package-maven-phase we using the maven-plugin to build the installer mediums
That works very nice. Now the company decided to buy a license-bundle including a floating license server. But how to include this to our build process? My suggestion would be the following:
install license server to a server reachable over the network
modify the config.xml file at the zipped application of the maven-repository and integrate the floating-license-server address or set maven-plugin-license property something like FLOAT:[server-ip]:11862 at the build configuration?
Is the license-key gotten by ej-technologie only necessary for using the ui? Has anybody some similar build environment and can give me some information how to setup this correctly?
Thanks in advance
set maven-plugin-license property something like FLOAT:[server-ip]:11862 at the build configuration?
That would work for the multi-platform edition. If you have the Windows edition, you have to go with:
modify the config.xml file at the zipped application of the maven-repository and integrate the floating-license-server address
As for:
Is the license-key gotten by ej-technologie only necessary for using the ui?
The license key is entered in the license server. Both IDE and command line compiler contact the license server. Only the IDE actually checks out a license as long as the IDE is open, the command line compiler just verifies the validity of the license.
I am trying to use Qt with QOCI (actually, along with other plugins as well) but for some reason I cannot. Here is what I did and result:
1- http://doc.qt.nokia.com/latest/sql-driver.html#qoci
plug-in is built successfully.
2- copied the plugin debug & release dll and lib files to plugins/sqldrivers and OCI.DLL to %WINDIR%\system32 (plugins/sqldrivers is where other plugins such as QPSQL and QMYSQL are)
3- QSqlDatabase::isDriverAvailable(QOCI) returns false where it returns true for QMYSQL and QPSQL. I did the same for QMYSQL and QPSQL
4- QStringList qsl = QSqlDatabase::drivers();
There is no QOCI in the string list returned. however there is QMYSQL, QPSQL and some others.
additional checks: opened qsqloci4.dll with dependency walker, 3 dlls were impossible to locate: 1-QtCore4.dll 2-QtSql4.dll 3-MSVSC80.dll However it is also impossible to locate them when opening qsqlpsql.dll with dependency walker. I believe that loading dll did not fail because of dependencies of qsqloci4.dll. But still, any ideas are welcomed.
NEWS
LoadLibrary(_T("C:\\QtSDK\\Desktop\\Qt\\4.7.3\\msvc2005\\plugins\\sqldrivers\\qsqloci4.dll");
and
LoadLibrary(_T("C:\\QtSDK\\Desktop\\Qt\\4.7.3\\msvc2005\\plugins\\sqldrivers\\qsqlocid4.dll");
fails!!! Please not that both of those files exist in the given path.
I believe that Qt also cannot load the plugin due to this error. Now question is a bit different but, why does LoadLibrary fail in this case? Any ideas?
Thanks in advance.
How to Build the Plugin on Windows
Choosing the option "Programmer" in the Oracle Client Installer from the Oracle Client Installation CD is sufficient to build the plugin.
Build the plugin as follows (here it is assumed that Oracle Client is installed in C:\oracle):
set INCLUDE=%INCLUDE%;c:\oracle\oci\include
set LIB=%LIB%;c:\oracle\oci\lib\msvc
cd %QTDIR%\src\plugins\sqldrivers\oci
qmake -o Makefile oci.pro
nmake
If you are not using a Microsoft compiler, replace nmake with make in the line above.
When you run your application you will also need to add the oci.dll path to your PATH environment variable:
set PATH=%PATH%;c:\oracle\bin
You need to create a folder call sqldrivers in the directory containing your exe. Put all the SQL driver DLLs you are using in there (for oracle oci.dll, ociw32.dll, oraociei12.dll, oraons.dll, qsqloci4.dll, qsqlocid4.dll).
My work project needs to be compiled and run under JDK1.5 and I'm on a Mac. I followed the instructions here to get 1.5 back on Snow Leopard, and it works fine when building from IntelliJ IDEA, or if I'm just in the same directory as the build.xml and try "ant CleanRebuild" When I "Run Target" in NetBeans they're all compiled with the wrong version resulting in
java.lang.UnsupportedClassVersionError:
Bad version number in .class file
(unable to load class...
when tomcat is trying to start up.
So things I've tried
Set the "Java Platform" to 1.5 under the project properties/libraries.
Set the Source/Binary Format to JDK 5 under project properties/sources.
Pointed the ant home to the ant I'm using under preferences/ant
Renaming every javac executable I could find in the hopes NetBeans would fail to compile and I could figure out which one it was using (no luck)
Setting 1.5 as the default, resulting in the need to point $netbeans_jdkhome to the 1.6 jdk in order for NetBeans to even start.
All unsuccessful....
Again, if I cd into the directory of the netbeans project with the build.xml and run the command manually all is well....so NetBeans. What's the deal?
Revised answer
Assumptions: NetBeans version 6.9.1 (although likely applicable to most or all 6.x versions), alternative build systems (e.g., Maven) are not used...the default (Ant) is used.
NetBeans, by default, uses Ant as its build system for doing things like compiling a project, building a project, cleaning built files from a project, etc. Ant has two concepts that are applicable here: targets and tasks. A target, in Ant's vocabulary, is simply a "command" or a series of jobs that need to be completed for a particular job. In NetBeans, common targets are "Compile", "Build", "Clean and Build", etc. The "jobs" that a target completes are (among other things) Ant tasks. In NetBeans one task (which is particularly relevant in answering this question) is the Javac Task. This is the task that Ant uses to compile .java files into .class files.
An Ant-based project, and therefore a NetBeans project, uses the file build.xml to control the build process and tell Ant how to go about accomplishing the targets. In a NetBeans project, the build.xml is found in the root directory of the project, by default. NetBeans, however, uses a user-extensible build.xml file. The core targets and tasks defined by NetBeans are actually located in nbprojects/build-impl.xml and imported into build.xml within the first few lines of the file. The theory is that users can add or override things in build.xml while the core NetBeans-defined configuration remains untouched in the build-impl.xml file.
If you look in the default nbproject/build-impl.xml file for a NetBeans Java project, you will find the Javac task referred to twice. (Search for "<javac".) Both are in macro definitions, and therefore deep within the complexities of NetBean's default build configuration. If we refer to the Javac Task documentation we find that the tasks uses the compiler in the location specified either by the global build.compiler property, by the compiler attribute specified with the <javac... /> task, or the default which is the Java compiler that is used when running and, and thus the one that is used when running NetBeans (because it is what fires off the Ant process). Since we don't see build.compiler or the compiler attribute anywhere (in the default build-impl.xml), then we can only conclude that the default is being used.
So here we have the (more-or-less correct) first answer. NetBeans compiles using the JDK that was used to execute NetBeans by default. It looks like it is actually a bit more complicated than that simple answer, but it is essentially correct. If you look at the documentation for the Javac Task it alludes to "a class that implements the CompilerAdapter interface", which suggests that rather than calling the javac executable directly, Ant (and therefore NetBeans) compiles using the compiler class (that, in all likelihood, the javac executable also uses). Refer to the Original answer below to determine which JDK what used to run NetBeans.
So, what if you don't want to use the default JDK that was used to run NetBeans? This is where "Java Platforms" comes in. Go to the Tools menu, and click on "Java Platforms". You likely only have one platform defined here. (As an aside, this is actually the most correct answer to what JDK is used by default... the one defined here in the Java Platform Manager.) If you would like to compile against another Java version (say your default JDK is 1.6, but you want to compile against 1.5) then you would install the alternate JDK somewhere on your system, and then configure a platform here in NetBeans' Java Platform Manager. (I'll leave it as an exercise for you to find the documentation on how to add a Java Platform. A superficial search of the wiki didn't turn up anything obvious. In any case, it's fairly self-explanatory.)
Once a new platform is created in the manager, you would right-click on your project in the Projects tab, click on "Properties", and then on "Libraries". At the top, you would select the appropriate Java platform for the project. As soon as you change this value and click on "OK", NetBeans makes several adjustments to your build-impl.xml file that point it to the new JDK against which to compile. (It is instructive for the truly geeky amongst us to make a copy of the nbproject directory before making this change and to diff that against the new contents of the nbproject directory after the change is made.) The changes instruct the Javac Ant Task to use the (equivalent of the) javac executable of the specified platform. So here we have the most correct answer: NetBeans uses the equivalent of the javac executable (as invoked by the Ant javac task) that is specified in the project's Java Platform located under the Libraries node of the project's properties.
Original answer
The path to the JDK used by NetBeans can be found in the netbeans.conf file. Look for the netbeans_jdkhome entry.
You can also specify the jdkhome at runtime (*NIX example given):
netbeans --jdkhome /usr/bin/jdk1.6.0_22
The netbeans.conf file is found in different places depending on what OS you are using. See the NetBeans.conf FAQ on the NetBeans wiki for help finding the file.
A few additional comments...
...You can specify the -target option in the project properties. In NetBeans 6.9 right-click on the project, and choose Properties. Click on the Compiling node. Add your -target to Additional Compiler Options.
...I have read in a few places that specifying a target is not a guarantee that the code will run on a JRE whose version is lower than the JDK that built it. In other words, the recommendation seems to be that if you want 1.5 binaries, then compile with the 1.5 JDK.