Re: [crypto] New Release
I have a feeling about both mingw or cygwin build output will be slower than microsoft-visual-studio build output... Just a feeling, but no evidence. Alex Remily 于2020年6月14日周日 上午7:02写道： > I used MinGW64. It does indeed ship with make. I can provide a link > to the distribution I used if there's interest. > > On Sat, Jun 13, 2020 at 6:26 PM Marcelo Vanzin wrote: > > > > Pretty sure I remember comments in the code about building with mingw > > on Windows (not cygwin). That should have a version of make, too, > > IIRC. > > > > On Sat, Jun 13, 2020 at 3:11 PM Gary Gregory > wrote: > > > > > > Except that you can't build on plain Windows because the build uses > make > > > and Microsoft version is called nmake. I might have to cobble up some > > > cygwin thing... > > > > > > Gary > > > > > > On Sat, Jun 13, 2020, 18:02 Alex Remily wrote: > > > > > > > I can't speak to how the original developers did the build, but all > > > > the Windows builds that I did were on a Windows machine. I always > > > > assumed that the original developers just manually packed the release > > > > jar with artifacts from each supported environment. I never did any > > > > investigation into the process. Is cobbling together a release in > > > > that manner really a non-starter here? > > > > > > > > Alex > > > > > > > > On Sat, Jun 13, 2020 at 5:44 PM Gary Gregory > > > > > wrote: > > > > > > > > > > Hi Matt: > > > > > > > > > > > I have: > > > > > > > > > > > > /mnt/c/git/commons-crypto# find /usr -name windows.h > > > > > > /usr/i686-w64-mingw32/include/windows.h > > > > > > /usr/share/mingw-w64/include/windows.h > > > > > > /usr/x86_64-w64-mingw32/include/windows.h > > > > > > > > > > > > Case matters here, so I wonder if the original others did not > cross > > > > > compile > > > > > > from Linux and instead built a little here, a little there, and > so on. > > > > > > > > > > > > I can see "-Ilib/inc_win" in the build but I am not sure where > that is > > > > > > supposed to be... > > > > > > > > > > Gary > > > > > > > > > > On Sat, Jun 13, 2020, 15:41 Matt Sicker wrote: > > > > > > > > > > > Are the Windows headers even available when using Ming32 or > Cygwin? > > > > > > That sounds more like a Visual Studio compiler thing. > > > > > > > > > > > > On Sat, 13 Jun 2020 at 09:29, Gary Gregory < > garydgreg...@gmail.com> > > > > wrote: > > > > > > > > > > > > > > The challenge is getting everything set up just right for > building > > > > the > > > > > > > various OS profiles. This component is quite different in this > > > > regard, > > > > > > > getting help from the original contributors would be helpful. > > > > > > > > > > > > > > After much fiddling to install the proper packages, this > builds OK: > > > > > > > > > > > > > > mvn package -DskipTests -P linux64 > > > > > > > mvn package -DskipTests -P linux32 > > > > > > > > > > > > > > But these do not: > > > > > > > mvn package -DskipTests -P win64 > > > > > > > mvn package -DskipTests -P win32 > > > > > > > > > > > > > > due to: > > > > > > > > > > > > > > [INFO] --- maven-antrun-plugin:1.8:run (make) @ commons-crypto > --- > > > > > > > [INFO] Executing tasks > > > > > > > > > > > > > > make: > > > > > > > [exec] make native CROSS_PREFIX=x86_64-w64-mingw32- > > > > OS_NAME=Windows > > > > > > > OS_ARCH=x86_64 > > > > > > > [exec] make[1]: Entering directory > '/mnt/c/git/commons-crypto' > > > > > > > [exec] x86_64-w64-mingw32-gcc > > > > > > > -I"/usr/lib/jvm/java-1.8.0-openjdk-amd64/include" -I"/include" > > > > > > > -Ilib/inc_win -O2 -fno-inline -Ilib/include -I/usr/include > > > > > > > -I"src/main/native/org/apache/commons/crypto/" > > > > > > > -I"/usr/lib/jvm/java-1.8.0-openjdk-amd64/include/linux" > > > > > > > -I"target/jni-classes/org/apache/commons/crypto/cipher" > > > > > > > -I"target/jni-classes/org/apache/commons/crypto/random" -c > > > > > > > > > > > > > > > > > > src/main/native/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.c > > > > > > > -o > > > > > > > > > > > > > > > > > > target/commons-crypto-1.1.0-SNAPSHOT-Windows-x86_64/OpenSslCryptoRandomNative.o > > > > > > > [exec] Makefile:54: recipe for target > > > > > > > > > > > > > > > > > > 'target/commons-crypto-1.1.0-SNAPSHOT-Windows-x86_64/OpenSslCryptoRandomNative.o' > > > > > > > failed > > > > > > > [exec] make[1]: Leaving directory > '/mnt/c/git/commons-crypto' > > > > > > > [exec] Makefile:82: recipe for target 'win64' failed > > > > > > > [exec] In file included from > > > > > > > > > > > > > > > > > > src/main/native/org/apache/commons/crypto/random/org_apache_commons_crypto_random.h:22:0, > > > > > > > [exec] from > > > > > > > > > > > > > > > > > > src/main/native/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.c:19: > > > > > > > [exec] > > > > > > > > > > > > > > > > > > src/main/native/org/apache/commons/crypto/org_apache_commons_crypto.h:151:10: > > > > > > > fatal error: Windows.h: No such
Re: [crypto] New Release
I used MinGW64. It does indeed ship with make. I can provide a link to the distribution I used if there's interest. On Sat, Jun 13, 2020 at 6:26 PM Marcelo Vanzin wrote: > > Pretty sure I remember comments in the code about building with mingw > on Windows (not cygwin). That should have a version of make, too, > IIRC. > > On Sat, Jun 13, 2020 at 3:11 PM Gary Gregory wrote: > > > > Except that you can't build on plain Windows because the build uses make > > and Microsoft version is called nmake. I might have to cobble up some > > cygwin thing... > > > > Gary > > > > On Sat, Jun 13, 2020, 18:02 Alex Remily wrote: > > > > > I can't speak to how the original developers did the build, but all > > > the Windows builds that I did were on a Windows machine. I always > > > assumed that the original developers just manually packed the release > > > jar with artifacts from each supported environment. I never did any > > > investigation into the process. Is cobbling together a release in > > > that manner really a non-starter here? > > > > > > Alex > > > > > > On Sat, Jun 13, 2020 at 5:44 PM Gary Gregory > > > wrote: > > > > > > > > Hi Matt: > > > > > > > > > I have: > > > > > > > > > > /mnt/c/git/commons-crypto# find /usr -name windows.h > > > > > /usr/i686-w64-mingw32/include/windows.h > > > > > /usr/share/mingw-w64/include/windows.h > > > > > /usr/x86_64-w64-mingw32/include/windows.h > > > > > > > > > > Case matters here, so I wonder if the original others did not cross > > > > compile > > > > > from Linux and instead built a little here, a little there, and so on. > > > > > > > > > > I can see "-Ilib/inc_win" in the build but I am not sure where that is > > > > > supposed to be... > > > > > > > > Gary > > > > > > > > On Sat, Jun 13, 2020, 15:41 Matt Sicker wrote: > > > > > > > > > Are the Windows headers even available when using Ming32 or Cygwin? > > > > > That sounds more like a Visual Studio compiler thing. > > > > > > > > > > On Sat, 13 Jun 2020 at 09:29, Gary Gregory > > > wrote: > > > > > > > > > > > > The challenge is getting everything set up just right for building > > > the > > > > > > various OS profiles. This component is quite different in this > > > regard, > > > > > > getting help from the original contributors would be helpful. > > > > > > > > > > > > After much fiddling to install the proper packages, this builds OK: > > > > > > > > > > > > mvn package -DskipTests -P linux64 > > > > > > mvn package -DskipTests -P linux32 > > > > > > > > > > > > But these do not: > > > > > > mvn package -DskipTests -P win64 > > > > > > mvn package -DskipTests -P win32 > > > > > > > > > > > > due to: > > > > > > > > > > > > [INFO] --- maven-antrun-plugin:1.8:run (make) @ commons-crypto --- > > > > > > [INFO] Executing tasks > > > > > > > > > > > > make: > > > > > > [exec] make native CROSS_PREFIX=x86_64-w64-mingw32- > > > OS_NAME=Windows > > > > > > OS_ARCH=x86_64 > > > > > > [exec] make[1]: Entering directory '/mnt/c/git/commons-crypto' > > > > > > [exec] x86_64-w64-mingw32-gcc > > > > > > -I"/usr/lib/jvm/java-1.8.0-openjdk-amd64/include" -I"/include" > > > > > > -Ilib/inc_win -O2 -fno-inline -Ilib/include -I/usr/include > > > > > > -I"src/main/native/org/apache/commons/crypto/" > > > > > > -I"/usr/lib/jvm/java-1.8.0-openjdk-amd64/include/linux" > > > > > > -I"target/jni-classes/org/apache/commons/crypto/cipher" > > > > > > -I"target/jni-classes/org/apache/commons/crypto/random" -c > > > > > > > > > > > > > > src/main/native/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.c > > > > > > -o > > > > > > > > > > > > > > target/commons-crypto-1.1.0-SNAPSHOT-Windows-x86_64/OpenSslCryptoRandomNative.o > > > > > > [exec] Makefile:54: recipe for target > > > > > > > > > > > > > > 'target/commons-crypto-1.1.0-SNAPSHOT-Windows-x86_64/OpenSslCryptoRandomNative.o' > > > > > > failed > > > > > > [exec] make[1]: Leaving directory '/mnt/c/git/commons-crypto' > > > > > > [exec] Makefile:82: recipe for target 'win64' failed > > > > > > [exec] In file included from > > > > > > > > > > > > > > src/main/native/org/apache/commons/crypto/random/org_apache_commons_crypto_random.h:22:0, > > > > > > [exec] from > > > > > > > > > > > > > > src/main/native/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.c:19: > > > > > > [exec] > > > > > > > > > > > > > > src/main/native/org/apache/commons/crypto/org_apache_commons_crypto.h:151:10: > > > > > > fatal error: Windows.h: No such file or directory > > > > > > [exec] #include > > > > > > [exec] ^~~ > > > > > > [exec] compilation terminated. > > > > > > [exec] make[1]: *** > > > > > > > > > > > > > > [target/commons-crypto-1.1.0-SNAPSHOT-Windows-x86_64/OpenSslCryptoRandomNative.o] > > > > > > Error 1 > > > > > > [exec] make: *** [win64] Error 2 > > > > > > [INFO] > > > > > > > > > > > > >
Re: [crypto] New Release
Use of cmake could be useful for cross platform builds, though I’ve only used some of the basic functionality so far and can’t comment on how big a task it is to convert to use. On Sat, Jun 13, 2020 at 17:26 Marcelo Vanzin wrote: > Pretty sure I remember comments in the code about building with mingw > on Windows (not cygwin). That should have a version of make, too, > IIRC. > > On Sat, Jun 13, 2020 at 3:11 PM Gary Gregory > wrote: > > > > Except that you can't build on plain Windows because the build uses make > > and Microsoft version is called nmake. I might have to cobble up some > > cygwin thing... > > > > Gary > > > > On Sat, Jun 13, 2020, 18:02 Alex Remily wrote: > > > > > I can't speak to how the original developers did the build, but all > > > the Windows builds that I did were on a Windows machine. I always > > > assumed that the original developers just manually packed the release > > > jar with artifacts from each supported environment. I never did any > > > investigation into the process. Is cobbling together a release in > > > that manner really a non-starter here? > > > > > > Alex > > > > > > On Sat, Jun 13, 2020 at 5:44 PM Gary Gregory > > > wrote: > > > > > > > > Hi Matt: > > > > > > > > > I have: > > > > > > > > > > /mnt/c/git/commons-crypto# find /usr -name windows.h > > > > > /usr/i686-w64-mingw32/include/windows.h > > > > > /usr/share/mingw-w64/include/windows.h > > > > > /usr/x86_64-w64-mingw32/include/windows.h > > > > > > > > > > Case matters here, so I wonder if the original others did not cross > > > > compile > > > > > from Linux and instead built a little here, a little there, and so > on. > > > > > > > > > > I can see "-Ilib/inc_win" in the build but I am not sure where > that is > > > > > supposed to be... > > > > > > > > Gary > > > > > > > > On Sat, Jun 13, 2020, 15:41 Matt Sicker wrote: > > > > > > > > > Are the Windows headers even available when using Ming32 or Cygwin? > > > > > That sounds more like a Visual Studio compiler thing. > > > > > > > > > > On Sat, 13 Jun 2020 at 09:29, Gary Gregory > > > > wrote: > > > > > > > > > > > > The challenge is getting everything set up just right for > building > > > the > > > > > > various OS profiles. This component is quite different in this > > > regard, > > > > > > getting help from the original contributors would be helpful. > > > > > > > > > > > > After much fiddling to install the proper packages, this builds > OK: > > > > > > > > > > > > mvn package -DskipTests -P linux64 > > > > > > mvn package -DskipTests -P linux32 > > > > > > > > > > > > But these do not: > > > > > > mvn package -DskipTests -P win64 > > > > > > mvn package -DskipTests -P win32 > > > > > > > > > > > > due to: > > > > > > > > > > > > [INFO] --- maven-antrun-plugin:1.8:run (make) @ commons-crypto > --- > > > > > > [INFO] Executing tasks > > > > > > > > > > > > make: > > > > > > [exec] make native CROSS_PREFIX=x86_64-w64-mingw32- > > > OS_NAME=Windows > > > > > > OS_ARCH=x86_64 > > > > > > [exec] make[1]: Entering directory > '/mnt/c/git/commons-crypto' > > > > > > [exec] x86_64-w64-mingw32-gcc > > > > > > -I"/usr/lib/jvm/java-1.8.0-openjdk-amd64/include" -I"/include" > > > > > > -Ilib/inc_win -O2 -fno-inline -Ilib/include -I/usr/include > > > > > > -I"src/main/native/org/apache/commons/crypto/" > > > > > > -I"/usr/lib/jvm/java-1.8.0-openjdk-amd64/include/linux" > > > > > > -I"target/jni-classes/org/apache/commons/crypto/cipher" > > > > > > -I"target/jni-classes/org/apache/commons/crypto/random" -c > > > > > > > > > > > > > > > src/main/native/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.c > > > > > > -o > > > > > > > > > > > > > > > target/commons-crypto-1.1.0-SNAPSHOT-Windows-x86_64/OpenSslCryptoRandomNative.o > > > > > > [exec] Makefile:54: recipe for target > > > > > > > > > > > > > > > 'target/commons-crypto-1.1.0-SNAPSHOT-Windows-x86_64/OpenSslCryptoRandomNative.o' > > > > > > failed > > > > > > [exec] make[1]: Leaving directory > '/mnt/c/git/commons-crypto' > > > > > > [exec] Makefile:82: recipe for target 'win64' failed > > > > > > [exec] In file included from > > > > > > > > > > > > > > > src/main/native/org/apache/commons/crypto/random/org_apache_commons_crypto_random.h:22:0, > > > > > > [exec] from > > > > > > > > > > > > > > > src/main/native/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.c:19: > > > > > > [exec] > > > > > > > > > > > > > > > src/main/native/org/apache/commons/crypto/org_apache_commons_crypto.h:151:10: > > > > > > fatal error: Windows.h: No such file or directory > > > > > > [exec] #include > > > > > > [exec] ^~~ > > > > > > [exec] compilation terminated. > > > > > > [exec] make[1]: *** > > > > > > > > > > > > > > > [target/commons-crypto-1.1.0-SNAPSHOT-Windows-x86_64/OpenSslCryptoRandomNative.o] > > > > > > Error 1 > > > > > > [exec] make: *** [win64] Error 2 > > > > > > [INFO] > > > > >
Re: [crypto] New Release
Pretty sure I remember comments in the code about building with mingw on Windows (not cygwin). That should have a version of make, too, IIRC. On Sat, Jun 13, 2020 at 3:11 PM Gary Gregory wrote: > > Except that you can't build on plain Windows because the build uses make > and Microsoft version is called nmake. I might have to cobble up some > cygwin thing... > > Gary > > On Sat, Jun 13, 2020, 18:02 Alex Remily wrote: > > > I can't speak to how the original developers did the build, but all > > the Windows builds that I did were on a Windows machine. I always > > assumed that the original developers just manually packed the release > > jar with artifacts from each supported environment. I never did any > > investigation into the process. Is cobbling together a release in > > that manner really a non-starter here? > > > > Alex > > > > On Sat, Jun 13, 2020 at 5:44 PM Gary Gregory > > wrote: > > > > > > Hi Matt: > > > > > > > I have: > > > > > > > > /mnt/c/git/commons-crypto# find /usr -name windows.h > > > > /usr/i686-w64-mingw32/include/windows.h > > > > /usr/share/mingw-w64/include/windows.h > > > > /usr/x86_64-w64-mingw32/include/windows.h > > > > > > > > Case matters here, so I wonder if the original others did not cross > > > compile > > > > from Linux and instead built a little here, a little there, and so on. > > > > > > > > I can see "-Ilib/inc_win" in the build but I am not sure where that is > > > > supposed to be... > > > > > > Gary > > > > > > On Sat, Jun 13, 2020, 15:41 Matt Sicker wrote: > > > > > > > Are the Windows headers even available when using Ming32 or Cygwin? > > > > That sounds more like a Visual Studio compiler thing. > > > > > > > > On Sat, 13 Jun 2020 at 09:29, Gary Gregory > > wrote: > > > > > > > > > > The challenge is getting everything set up just right for building > > the > > > > > various OS profiles. This component is quite different in this > > regard, > > > > > getting help from the original contributors would be helpful. > > > > > > > > > > After much fiddling to install the proper packages, this builds OK: > > > > > > > > > > mvn package -DskipTests -P linux64 > > > > > mvn package -DskipTests -P linux32 > > > > > > > > > > But these do not: > > > > > mvn package -DskipTests -P win64 > > > > > mvn package -DskipTests -P win32 > > > > > > > > > > due to: > > > > > > > > > > [INFO] --- maven-antrun-plugin:1.8:run (make) @ commons-crypto --- > > > > > [INFO] Executing tasks > > > > > > > > > > make: > > > > > [exec] make native CROSS_PREFIX=x86_64-w64-mingw32- > > OS_NAME=Windows > > > > > OS_ARCH=x86_64 > > > > > [exec] make[1]: Entering directory '/mnt/c/git/commons-crypto' > > > > > [exec] x86_64-w64-mingw32-gcc > > > > > -I"/usr/lib/jvm/java-1.8.0-openjdk-amd64/include" -I"/include" > > > > > -Ilib/inc_win -O2 -fno-inline -Ilib/include -I/usr/include > > > > > -I"src/main/native/org/apache/commons/crypto/" > > > > > -I"/usr/lib/jvm/java-1.8.0-openjdk-amd64/include/linux" > > > > > -I"target/jni-classes/org/apache/commons/crypto/cipher" > > > > > -I"target/jni-classes/org/apache/commons/crypto/random" -c > > > > > > > > > > > src/main/native/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.c > > > > > -o > > > > > > > > > > > target/commons-crypto-1.1.0-SNAPSHOT-Windows-x86_64/OpenSslCryptoRandomNative.o > > > > > [exec] Makefile:54: recipe for target > > > > > > > > > > > 'target/commons-crypto-1.1.0-SNAPSHOT-Windows-x86_64/OpenSslCryptoRandomNative.o' > > > > > failed > > > > > [exec] make[1]: Leaving directory '/mnt/c/git/commons-crypto' > > > > > [exec] Makefile:82: recipe for target 'win64' failed > > > > > [exec] In file included from > > > > > > > > > > > src/main/native/org/apache/commons/crypto/random/org_apache_commons_crypto_random.h:22:0, > > > > > [exec] from > > > > > > > > > > > src/main/native/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.c:19: > > > > > [exec] > > > > > > > > > > > src/main/native/org/apache/commons/crypto/org_apache_commons_crypto.h:151:10: > > > > > fatal error: Windows.h: No such file or directory > > > > > [exec] #include > > > > > [exec] ^~~ > > > > > [exec] compilation terminated. > > > > > [exec] make[1]: *** > > > > > > > > > > > [target/commons-crypto-1.1.0-SNAPSHOT-Windows-x86_64/OpenSslCryptoRandomNative.o] > > > > > Error 1 > > > > > [exec] make: *** [win64] Error 2 > > > > > [INFO] > > > > > > > > > > > > [INFO] BUILD FAILURE > > > > > [INFO] > > > > > > > > > > > > [INFO] Total time: 10.107 s > > > > > [INFO] Finished at: 2020-06-13T13:58:50Z > > > > > [INFO] > > > > > > > > > > > > [ERROR] Failed to execute goal > > > > > org.apache.maven.plugins:maven-antrun-plugin:1.8:
Re: [crypto] New Release
Except that you can't build on plain Windows because the build uses make and Microsoft version is called nmake. I might have to cobble up some cygwin thing... Gary On Sat, Jun 13, 2020, 18:02 Alex Remily wrote: > I can't speak to how the original developers did the build, but all > the Windows builds that I did were on a Windows machine. I always > assumed that the original developers just manually packed the release > jar with artifacts from each supported environment. I never did any > investigation into the process. Is cobbling together a release in > that manner really a non-starter here? > > Alex > > On Sat, Jun 13, 2020 at 5:44 PM Gary Gregory > wrote: > > > > Hi Matt: > > > > > I have: > > > > > > /mnt/c/git/commons-crypto# find /usr -name windows.h > > > /usr/i686-w64-mingw32/include/windows.h > > > /usr/share/mingw-w64/include/windows.h > > > /usr/x86_64-w64-mingw32/include/windows.h > > > > > > Case matters here, so I wonder if the original others did not cross > > compile > > > from Linux and instead built a little here, a little there, and so on. > > > > > > I can see "-Ilib/inc_win" in the build but I am not sure where that is > > > supposed to be... > > > > Gary > > > > On Sat, Jun 13, 2020, 15:41 Matt Sicker wrote: > > > > > Are the Windows headers even available when using Ming32 or Cygwin? > > > That sounds more like a Visual Studio compiler thing. > > > > > > On Sat, 13 Jun 2020 at 09:29, Gary Gregory > wrote: > > > > > > > > The challenge is getting everything set up just right for building > the > > > > various OS profiles. This component is quite different in this > regard, > > > > getting help from the original contributors would be helpful. > > > > > > > > After much fiddling to install the proper packages, this builds OK: > > > > > > > > mvn package -DskipTests -P linux64 > > > > mvn package -DskipTests -P linux32 > > > > > > > > But these do not: > > > > mvn package -DskipTests -P win64 > > > > mvn package -DskipTests -P win32 > > > > > > > > due to: > > > > > > > > [INFO] --- maven-antrun-plugin:1.8:run (make) @ commons-crypto --- > > > > [INFO] Executing tasks > > > > > > > > make: > > > > [exec] make native CROSS_PREFIX=x86_64-w64-mingw32- > OS_NAME=Windows > > > > OS_ARCH=x86_64 > > > > [exec] make[1]: Entering directory '/mnt/c/git/commons-crypto' > > > > [exec] x86_64-w64-mingw32-gcc > > > > -I"/usr/lib/jvm/java-1.8.0-openjdk-amd64/include" -I"/include" > > > > -Ilib/inc_win -O2 -fno-inline -Ilib/include -I/usr/include > > > > -I"src/main/native/org/apache/commons/crypto/" > > > > -I"/usr/lib/jvm/java-1.8.0-openjdk-amd64/include/linux" > > > > -I"target/jni-classes/org/apache/commons/crypto/cipher" > > > > -I"target/jni-classes/org/apache/commons/crypto/random" -c > > > > > > > > src/main/native/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.c > > > > -o > > > > > > > > target/commons-crypto-1.1.0-SNAPSHOT-Windows-x86_64/OpenSslCryptoRandomNative.o > > > > [exec] Makefile:54: recipe for target > > > > > > > > 'target/commons-crypto-1.1.0-SNAPSHOT-Windows-x86_64/OpenSslCryptoRandomNative.o' > > > > failed > > > > [exec] make[1]: Leaving directory '/mnt/c/git/commons-crypto' > > > > [exec] Makefile:82: recipe for target 'win64' failed > > > > [exec] In file included from > > > > > > > > src/main/native/org/apache/commons/crypto/random/org_apache_commons_crypto_random.h:22:0, > > > > [exec] from > > > > > > > > src/main/native/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.c:19: > > > > [exec] > > > > > > > > src/main/native/org/apache/commons/crypto/org_apache_commons_crypto.h:151:10: > > > > fatal error: Windows.h: No such file or directory > > > > [exec] #include > > > > [exec] ^~~ > > > > [exec] compilation terminated. > > > > [exec] make[1]: *** > > > > > > > > [target/commons-crypto-1.1.0-SNAPSHOT-Windows-x86_64/OpenSslCryptoRandomNative.o] > > > > Error 1 > > > > [exec] make: *** [win64] Error 2 > > > > [INFO] > > > > > > > > > [INFO] BUILD FAILURE > > > > [INFO] > > > > > > > > > [INFO] Total time: 10.107 s > > > > [INFO] Finished at: 2020-06-13T13:58:50Z > > > > [INFO] > > > > > > > > > [ERROR] Failed to execute goal > > > > org.apache.maven.plugins:maven-antrun-plugin:1.8:run (make) on > project > > > > commons-crypto: An Ant BuildException has occured: exec returned: 2 > > > > [ERROR] around Ant part ... > > > dir="/mnt/c/git/commons-crypto" executable="make">... @ 5:78 in > > > > /mnt/c/git/commons-crypto/target/antrun/build-make.xml > > > > > > > > I have: > > > > > > > > /mnt/c/git/commons-crypto# find /usr -name windows.h > > > > /usr/i686-w64-mingw32/include/windows.h > > > > /usr/share/mingw-w64/include/wind
Re: [crypto] New Release
I can't speak to how the original developers did the build, but all the Windows builds that I did were on a Windows machine. I always assumed that the original developers just manually packed the release jar with artifacts from each supported environment. I never did any investigation into the process. Is cobbling together a release in that manner really a non-starter here? Alex On Sat, Jun 13, 2020 at 5:44 PM Gary Gregory wrote: > > Hi Matt: > > > I have: > > > > /mnt/c/git/commons-crypto# find /usr -name windows.h > > /usr/i686-w64-mingw32/include/windows.h > > /usr/share/mingw-w64/include/windows.h > > /usr/x86_64-w64-mingw32/include/windows.h > > > > Case matters here, so I wonder if the original others did not cross > compile > > from Linux and instead built a little here, a little there, and so on. > > > > I can see "-Ilib/inc_win" in the build but I am not sure where that is > > supposed to be... > > Gary > > On Sat, Jun 13, 2020, 15:41 Matt Sicker wrote: > > > Are the Windows headers even available when using Ming32 or Cygwin? > > That sounds more like a Visual Studio compiler thing. > > > > On Sat, 13 Jun 2020 at 09:29, Gary Gregory wrote: > > > > > > The challenge is getting everything set up just right for building the > > > various OS profiles. This component is quite different in this regard, > > > getting help from the original contributors would be helpful. > > > > > > After much fiddling to install the proper packages, this builds OK: > > > > > > mvn package -DskipTests -P linux64 > > > mvn package -DskipTests -P linux32 > > > > > > But these do not: > > > mvn package -DskipTests -P win64 > > > mvn package -DskipTests -P win32 > > > > > > due to: > > > > > > [INFO] --- maven-antrun-plugin:1.8:run (make) @ commons-crypto --- > > > [INFO] Executing tasks > > > > > > make: > > > [exec] make native CROSS_PREFIX=x86_64-w64-mingw32- OS_NAME=Windows > > > OS_ARCH=x86_64 > > > [exec] make[1]: Entering directory '/mnt/c/git/commons-crypto' > > > [exec] x86_64-w64-mingw32-gcc > > > -I"/usr/lib/jvm/java-1.8.0-openjdk-amd64/include" -I"/include" > > > -Ilib/inc_win -O2 -fno-inline -Ilib/include -I/usr/include > > > -I"src/main/native/org/apache/commons/crypto/" > > > -I"/usr/lib/jvm/java-1.8.0-openjdk-amd64/include/linux" > > > -I"target/jni-classes/org/apache/commons/crypto/cipher" > > > -I"target/jni-classes/org/apache/commons/crypto/random" -c > > > > > src/main/native/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.c > > > -o > > > > > target/commons-crypto-1.1.0-SNAPSHOT-Windows-x86_64/OpenSslCryptoRandomNative.o > > > [exec] Makefile:54: recipe for target > > > > > 'target/commons-crypto-1.1.0-SNAPSHOT-Windows-x86_64/OpenSslCryptoRandomNative.o' > > > failed > > > [exec] make[1]: Leaving directory '/mnt/c/git/commons-crypto' > > > [exec] Makefile:82: recipe for target 'win64' failed > > > [exec] In file included from > > > > > src/main/native/org/apache/commons/crypto/random/org_apache_commons_crypto_random.h:22:0, > > > [exec] from > > > > > src/main/native/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.c:19: > > > [exec] > > > > > src/main/native/org/apache/commons/crypto/org_apache_commons_crypto.h:151:10: > > > fatal error: Windows.h: No such file or directory > > > [exec] #include > > > [exec] ^~~ > > > [exec] compilation terminated. > > > [exec] make[1]: *** > > > > > [target/commons-crypto-1.1.0-SNAPSHOT-Windows-x86_64/OpenSslCryptoRandomNative.o] > > > Error 1 > > > [exec] make: *** [win64] Error 2 > > > [INFO] > > > > > > [INFO] BUILD FAILURE > > > [INFO] > > > > > > [INFO] Total time: 10.107 s > > > [INFO] Finished at: 2020-06-13T13:58:50Z > > > [INFO] > > > > > > [ERROR] Failed to execute goal > > > org.apache.maven.plugins:maven-antrun-plugin:1.8:run (make) on project > > > commons-crypto: An Ant BuildException has occured: exec returned: 2 > > > [ERROR] around Ant part ... > > dir="/mnt/c/git/commons-crypto" executable="make">... @ 5:78 in > > > /mnt/c/git/commons-crypto/target/antrun/build-make.xml > > > > > > I have: > > > > > > /mnt/c/git/commons-crypto# find /usr -name windows.h > > > /usr/i686-w64-mingw32/include/windows.h > > > /usr/share/mingw-w64/include/windows.h > > > /usr/x86_64-w64-mingw32/include/windows.h > > > > > > Case matters here, so I wonder if the original others did not cross > > compile > > > from Linux and instead built a little here, a little there, and so on. > > > > > > I can see "-Ilib/inc_win" in the build but I am not sure where that is > > > supposed to be... > > > > > > Building with mac64 profile is no better: > > > > > > mvn package -DskipTests -P mac64 > > > > > > [INFO] --- maven-antrun-plugin:1.8
Re: [crypto] New Release
Hi Matt: > I have: > > /mnt/c/git/commons-crypto# find /usr -name windows.h > /usr/i686-w64-mingw32/include/windows.h > /usr/share/mingw-w64/include/windows.h > /usr/x86_64-w64-mingw32/include/windows.h > > Case matters here, so I wonder if the original others did not cross compile > from Linux and instead built a little here, a little there, and so on. > > I can see "-Ilib/inc_win" in the build but I am not sure where that is > supposed to be... Gary On Sat, Jun 13, 2020, 15:41 Matt Sicker wrote: > Are the Windows headers even available when using Ming32 or Cygwin? > That sounds more like a Visual Studio compiler thing. > > On Sat, 13 Jun 2020 at 09:29, Gary Gregory wrote: > > > > The challenge is getting everything set up just right for building the > > various OS profiles. This component is quite different in this regard, > > getting help from the original contributors would be helpful. > > > > After much fiddling to install the proper packages, this builds OK: > > > > mvn package -DskipTests -P linux64 > > mvn package -DskipTests -P linux32 > > > > But these do not: > > mvn package -DskipTests -P win64 > > mvn package -DskipTests -P win32 > > > > due to: > > > > [INFO] --- maven-antrun-plugin:1.8:run (make) @ commons-crypto --- > > [INFO] Executing tasks > > > > make: > > [exec] make native CROSS_PREFIX=x86_64-w64-mingw32- OS_NAME=Windows > > OS_ARCH=x86_64 > > [exec] make[1]: Entering directory '/mnt/c/git/commons-crypto' > > [exec] x86_64-w64-mingw32-gcc > > -I"/usr/lib/jvm/java-1.8.0-openjdk-amd64/include" -I"/include" > > -Ilib/inc_win -O2 -fno-inline -Ilib/include -I/usr/include > > -I"src/main/native/org/apache/commons/crypto/" > > -I"/usr/lib/jvm/java-1.8.0-openjdk-amd64/include/linux" > > -I"target/jni-classes/org/apache/commons/crypto/cipher" > > -I"target/jni-classes/org/apache/commons/crypto/random" -c > > > src/main/native/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.c > > -o > > > target/commons-crypto-1.1.0-SNAPSHOT-Windows-x86_64/OpenSslCryptoRandomNative.o > > [exec] Makefile:54: recipe for target > > > 'target/commons-crypto-1.1.0-SNAPSHOT-Windows-x86_64/OpenSslCryptoRandomNative.o' > > failed > > [exec] make[1]: Leaving directory '/mnt/c/git/commons-crypto' > > [exec] Makefile:82: recipe for target 'win64' failed > > [exec] In file included from > > > src/main/native/org/apache/commons/crypto/random/org_apache_commons_crypto_random.h:22:0, > > [exec] from > > > src/main/native/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.c:19: > > [exec] > > > src/main/native/org/apache/commons/crypto/org_apache_commons_crypto.h:151:10: > > fatal error: Windows.h: No such file or directory > > [exec] #include > > [exec] ^~~ > > [exec] compilation terminated. > > [exec] make[1]: *** > > > [target/commons-crypto-1.1.0-SNAPSHOT-Windows-x86_64/OpenSslCryptoRandomNative.o] > > Error 1 > > [exec] make: *** [win64] Error 2 > > [INFO] > > > > [INFO] BUILD FAILURE > > [INFO] > > > > [INFO] Total time: 10.107 s > > [INFO] Finished at: 2020-06-13T13:58:50Z > > [INFO] > > > > [ERROR] Failed to execute goal > > org.apache.maven.plugins:maven-antrun-plugin:1.8:run (make) on project > > commons-crypto: An Ant BuildException has occured: exec returned: 2 > > [ERROR] around Ant part ... > dir="/mnt/c/git/commons-crypto" executable="make">... @ 5:78 in > > /mnt/c/git/commons-crypto/target/antrun/build-make.xml > > > > I have: > > > > /mnt/c/git/commons-crypto# find /usr -name windows.h > > /usr/i686-w64-mingw32/include/windows.h > > /usr/share/mingw-w64/include/windows.h > > /usr/x86_64-w64-mingw32/include/windows.h > > > > Case matters here, so I wonder if the original others did not cross > compile > > from Linux and instead built a little here, a little there, and so on. > > > > I can see "-Ilib/inc_win" in the build but I am not sure where that is > > supposed to be... > > > > Building with mac64 profile is no better: > > > > mvn package -DskipTests -P mac64 > > > > [INFO] --- maven-antrun-plugin:1.8:run (make) @ commons-crypto --- > > [INFO] Executing tasks > > > > make: > > [exec] make native OS_NAME=Mac OS_ARCH=x86_64 > > [exec] make[1]: Entering directory '/mnt/c/git/commons-crypto' > > [exec] gcc -arch x86_64 -Ilib/inc_mac > > -I"/usr/lib/jvm/java-1.8.0-openjdk-amd64/include" -O2 -fPIC > > -mmacosx-version-min=10.7 -fvisibility=hidden -I/usr/local/include > > -I/usr/local/opt/openssl/include -Ilib/include -I/usr/include > > -I"src/main/native/org/apache/commons/crypto/" > > -I"/usr/lib/jvm/java-1.8.0-openjdk-amd64/include/linux" > > -I"target/jni-classes/org/apache/commons/crypto/cipher" > > -I"target/jni-classes/org/apache/commons/crypto/ra
Re: [crypto] New Release
Are the Windows headers even available when using Ming32 or Cygwin? That sounds more like a Visual Studio compiler thing. On Sat, 13 Jun 2020 at 09:29, Gary Gregory wrote: > > The challenge is getting everything set up just right for building the > various OS profiles. This component is quite different in this regard, > getting help from the original contributors would be helpful. > > After much fiddling to install the proper packages, this builds OK: > > mvn package -DskipTests -P linux64 > mvn package -DskipTests -P linux32 > > But these do not: > mvn package -DskipTests -P win64 > mvn package -DskipTests -P win32 > > due to: > > [INFO] --- maven-antrun-plugin:1.8:run (make) @ commons-crypto --- > [INFO] Executing tasks > > make: > [exec] make native CROSS_PREFIX=x86_64-w64-mingw32- OS_NAME=Windows > OS_ARCH=x86_64 > [exec] make[1]: Entering directory '/mnt/c/git/commons-crypto' > [exec] x86_64-w64-mingw32-gcc > -I"/usr/lib/jvm/java-1.8.0-openjdk-amd64/include" -I"/include" > -Ilib/inc_win -O2 -fno-inline -Ilib/include -I/usr/include > -I"src/main/native/org/apache/commons/crypto/" > -I"/usr/lib/jvm/java-1.8.0-openjdk-amd64/include/linux" > -I"target/jni-classes/org/apache/commons/crypto/cipher" > -I"target/jni-classes/org/apache/commons/crypto/random" -c > src/main/native/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.c > -o > target/commons-crypto-1.1.0-SNAPSHOT-Windows-x86_64/OpenSslCryptoRandomNative.o > [exec] Makefile:54: recipe for target > 'target/commons-crypto-1.1.0-SNAPSHOT-Windows-x86_64/OpenSslCryptoRandomNative.o' > failed > [exec] make[1]: Leaving directory '/mnt/c/git/commons-crypto' > [exec] Makefile:82: recipe for target 'win64' failed > [exec] In file included from > src/main/native/org/apache/commons/crypto/random/org_apache_commons_crypto_random.h:22:0, > [exec] from > src/main/native/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.c:19: > [exec] > src/main/native/org/apache/commons/crypto/org_apache_commons_crypto.h:151:10: > fatal error: Windows.h: No such file or directory > [exec] #include > [exec] ^~~ > [exec] compilation terminated. > [exec] make[1]: *** > [target/commons-crypto-1.1.0-SNAPSHOT-Windows-x86_64/OpenSslCryptoRandomNative.o] > Error 1 > [exec] make: *** [win64] Error 2 > [INFO] > > [INFO] BUILD FAILURE > [INFO] > > [INFO] Total time: 10.107 s > [INFO] Finished at: 2020-06-13T13:58:50Z > [INFO] > > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-antrun-plugin:1.8:run (make) on project > commons-crypto: An Ant BuildException has occured: exec returned: 2 > [ERROR] around Ant part ... dir="/mnt/c/git/commons-crypto" executable="make">... @ 5:78 in > /mnt/c/git/commons-crypto/target/antrun/build-make.xml > > I have: > > /mnt/c/git/commons-crypto# find /usr -name windows.h > /usr/i686-w64-mingw32/include/windows.h > /usr/share/mingw-w64/include/windows.h > /usr/x86_64-w64-mingw32/include/windows.h > > Case matters here, so I wonder if the original others did not cross compile > from Linux and instead built a little here, a little there, and so on. > > I can see "-Ilib/inc_win" in the build but I am not sure where that is > supposed to be... > > Building with mac64 profile is no better: > > mvn package -DskipTests -P mac64 > > [INFO] --- maven-antrun-plugin:1.8:run (make) @ commons-crypto --- > [INFO] Executing tasks > > make: > [exec] make native OS_NAME=Mac OS_ARCH=x86_64 > [exec] make[1]: Entering directory '/mnt/c/git/commons-crypto' > [exec] gcc -arch x86_64 -Ilib/inc_mac > -I"/usr/lib/jvm/java-1.8.0-openjdk-amd64/include" -O2 -fPIC > -mmacosx-version-min=10.7 -fvisibility=hidden -I/usr/local/include > -I/usr/local/opt/openssl/include -Ilib/include -I/usr/include > -I"src/main/native/org/apache/commons/crypto/" > -I"/usr/lib/jvm/java-1.8.0-openjdk-amd64/include/linux" > -I"target/jni-classes/org/apache/commons/crypto/cipher" > -I"target/jni-classes/org/apache/commons/crypto/random" -c > src/main/native/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.c > -o > target/commons-crypto-1.1.0-SNAPSHOT-Mac-x86_64/OpenSslCryptoRandomNative.o > [exec] Makefile:54: recipe for target > 'target/commons-crypto-1.1.0-SNAPSHOT-Mac-x86_64/OpenSslCryptoRandomNative.o' > failed > [exec] make[1]: Leaving directory '/mnt/c/git/commons-crypto' > [exec] Makefile:88: recipe for target 'mac64' failed > [exec] gcc: error: x86_64: No such file or directory > [exec] gcc: error: unrecognized command line option ‘-arch’; did you > mean ‘-march=’? > [exec] gcc: error: unrecognized command line option > ‘-mmacosx-version-min=10.7’ > [exec] make[1]: *** > [target/commons-crypto-
Re: [Graph] Build fails (unit tests)
On Sat, Jun 13, 2020 at 8:50 PM Gilles Sadowski wrote: > Hi. > > 2020-06-13 16:57 UTC+02:00, Amey Jadiye : > > Hello Gilles, > > > > On Sat, Jun 13, 2020 at 6:36 PM Gilles Sadowski > > wrote: > > > >> Hello. > >> > >> After the migration from SVN to "gitbox", we noticed that the > >> _first_ build failed due to 3 unit tests not passing (see e.g. the > >> Travis report referred to the JIRA report[1]). > >> > >> The move to "git" was intended to make it easier for people > >> willing to revive the [Graph] project. > >> > >> IMO, the top priority is now to fix the failing unit tests; > >> personally, I'm not going to merge any PR before that is > >> achieved (and please refer to the JIRA identifier[1] in the > >> corresponding commit/PR). > >> > > > > Indeed, that's what I think too. I have tried to stop bleeding > > commons-graph for now PR https://github.com/apache/commons-graph/pull/3, > > along with some more small nitty-gritty. > > > > > >> Furthermore, I'd suggest that branch "modularization" > >> becomes the reference branch (in place of "master"[2]), > >> since the latest batch of work for [Graph] was done on > >> that one, seemingly leaving "master" behind (TBC by > >> Amey?). [This path might avoid subsequent work of > >> merging the fixed (but outdated) "master" into the more > >> recent branch that is bound to replace it anyway...] > >> > > > > I am on the way to push my changes to master regarding modularization. I > > have more intention to push changes in master now. > > > > 1. I have just stopped bleeding due to failing test cases, with TODO > > marking though, so we can pull this work later once the > > "modularized" version of the comons-graph becomes stable in "master". > > Please open a JIRA report for this issue (with one sub-task > per module created, if you wish) > Upon completion please submit a single PR, with a single > commit per sub-task/module. > > Since this was a sandbox, abandoned, project, I don't care > about what, and how many, changes that will involve: I won't > have time to review them anyway. > If others have a different opinion, they should indicate their > willingness to perform more fine-grained reviews. > > If no one steps forward, then please try and follow the code > style used in "Commons RNG" (i.e. change the style of the > source code: e.g. no space after an opening parenthesis or > before a closing one, etc.). Perhaps someone can suggest > some IDE plugin that will automatically update the whole > code base... > > > > > 2. I'm comparing each and every class from master to a modularized > version > > of graph to make sure we don't miss anything behind from master. > > +1 > Thanks! > > > 3. we should not take my merge in functional code in the meantime, other > > related to Travis, Builds, Coverall is ok to accept as it > > doesn't interfere with /src. > > I didn't get what you mean. > > sorry for my English, I meant that taking chances in the current master is of no use. All addition/changes related to graph, algorithms, tests should go to a new modularized code. all the changes in /src should be stopped for now. other changes outsite /src can be merged. Regards, Amey > Regards, > Gilles > > >> > >> [1] https://issues.apache.org/jira/browse/SANDBOX-510 > >> [2] Even though the names of the maven "modules" should > >> be changed (for the sake of code layout "standardization" > >> with other modular components such as "Commons RNG"). > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [Graph] Build fails (unit tests)
Hi. 2020-06-13 16:57 UTC+02:00, Amey Jadiye : > Hello Gilles, > > On Sat, Jun 13, 2020 at 6:36 PM Gilles Sadowski > wrote: > >> Hello. >> >> After the migration from SVN to "gitbox", we noticed that the >> _first_ build failed due to 3 unit tests not passing (see e.g. the >> Travis report referred to the JIRA report[1]). >> >> The move to "git" was intended to make it easier for people >> willing to revive the [Graph] project. >> >> IMO, the top priority is now to fix the failing unit tests; >> personally, I'm not going to merge any PR before that is >> achieved (and please refer to the JIRA identifier[1] in the >> corresponding commit/PR). >> > > Indeed, that's what I think too. I have tried to stop bleeding > commons-graph for now PR https://github.com/apache/commons-graph/pull/3, > along with some more small nitty-gritty. > > >> Furthermore, I'd suggest that branch "modularization" >> becomes the reference branch (in place of "master"[2]), >> since the latest batch of work for [Graph] was done on >> that one, seemingly leaving "master" behind (TBC by >> Amey?). [This path might avoid subsequent work of >> merging the fixed (but outdated) "master" into the more >> recent branch that is bound to replace it anyway...] >> > > I am on the way to push my changes to master regarding modularization. I > have more intention to push changes in master now. > > 1. I have just stopped bleeding due to failing test cases, with TODO > marking though, so we can pull this work later once the > "modularized" version of the comons-graph becomes stable in "master". Please open a JIRA report for this issue (with one sub-task per module created, if you wish) Upon completion please submit a single PR, with a single commit per sub-task/module. Since this was a sandbox, abandoned, project, I don't care about what, and how many, changes that will involve: I won't have time to review them anyway. If others have a different opinion, they should indicate their willingness to perform more fine-grained reviews. If no one steps forward, then please try and follow the code style used in "Commons RNG" (i.e. change the style of the source code: e.g. no space after an opening parenthesis or before a closing one, etc.). Perhaps someone can suggest some IDE plugin that will automatically update the whole code base... > > 2. I'm comparing each and every class from master to a modularized version > of graph to make sure we don't miss anything behind from master. +1 Thanks! > 3. we should not take my merge in functional code in the meantime, other > related to Travis, Builds, Coverall is ok to accept as it > doesn't interfere with /src. I didn't get what you mean. Regards, Gilles >> >> [1] https://issues.apache.org/jira/browse/SANDBOX-510 >> [2] Even though the names of the maven "modules" should >> be changed (for the sake of code layout "standardization" >> with other modular components such as "Commons RNG"). - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Graph] Build fails (unit tests)
On Sat, Jun 13, 2020 at 8:27 PM Amey Jadiye wrote: > Hello Gilles, > > On Sat, Jun 13, 2020 at 6:36 PM Gilles Sadowski > wrote: > >> Hello. >> >> After the migration from SVN to "gitbox", we noticed that the >> _first_ build failed due to 3 unit tests not passing (see e.g. the >> Travis report referred to the JIRA report[1]). >> >> The move to "git" was intended to make it easier for people >> willing to revive the [Graph] project. >> >> IMO, the top priority is now to fix the failing unit tests; >> personally, I'm not going to merge any PR before that is >> achieved (and please refer to the JIRA identifier[1] in the >> corresponding commit/PR). >> > > Indeed, that's what I think too. I have tried to stop bleeding > commons-graph for now PR https://github.com/apache/commons-graph/pull/3, > along with some more small nitty-gritty. > > >> Furthermore, I'd suggest that branch "modularization" >> becomes the reference branch (in place of "master"[2]), >> since the latest batch of work for [Graph] was done on >> that one, seemingly leaving "master" behind (TBC by >> Amey?). [This path might avoid subsequent work of >> merging the fixed (but outdated) "master" into the more >> recent branch that is bound to replace it anyway...] >> > > I am on the way to push my changes to master regarding modularization. I > have more intention to push changes in master now. > typo mistake, I have *no more* intension to push in master :-) > > 1. I have just stopped bleeding due to failing test cases, with TODO > marking though, so we can pull this work later once the > "modularized" version of the comons-graph becomes stable in "master". > > 2. I'm comparing each and every class from master to a modularized version > of graph to make sure we don't miss anything behind from master. > > 3. we should not take my merge in functional code in the meantime, other > related to Travis, Builds, Coverall is ok to accept as it > doesn't interfere with /src. > > Regards, > Amey > > >> >> Thanks, >> Gilles >> >> [1] https://issues.apache.org/jira/browse/SANDBOX-510 >> [2] Even though the names of the maven "modules" should >> be changed (for the sake of code layout "standardization" >> with other modular components such as "Commons RNG"). >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >>
Re: [Graph] Build fails (unit tests)
Hello Gilles, On Sat, Jun 13, 2020 at 6:36 PM Gilles Sadowski wrote: > Hello. > > After the migration from SVN to "gitbox", we noticed that the > _first_ build failed due to 3 unit tests not passing (see e.g. the > Travis report referred to the JIRA report[1]). > > The move to "git" was intended to make it easier for people > willing to revive the [Graph] project. > > IMO, the top priority is now to fix the failing unit tests; > personally, I'm not going to merge any PR before that is > achieved (and please refer to the JIRA identifier[1] in the > corresponding commit/PR). > Indeed, that's what I think too. I have tried to stop bleeding commons-graph for now PR https://github.com/apache/commons-graph/pull/3, along with some more small nitty-gritty. > Furthermore, I'd suggest that branch "modularization" > becomes the reference branch (in place of "master"[2]), > since the latest batch of work for [Graph] was done on > that one, seemingly leaving "master" behind (TBC by > Amey?). [This path might avoid subsequent work of > merging the fixed (but outdated) "master" into the more > recent branch that is bound to replace it anyway...] > I am on the way to push my changes to master regarding modularization. I have more intention to push changes in master now. 1. I have just stopped bleeding due to failing test cases, with TODO marking though, so we can pull this work later once the "modularized" version of the comons-graph becomes stable in "master". 2. I'm comparing each and every class from master to a modularized version of graph to make sure we don't miss anything behind from master. 3. we should not take my merge in functional code in the meantime, other related to Travis, Builds, Coverall is ok to accept as it doesn't interfere with /src. Regards, Amey > > Thanks, > Gilles > > [1] https://issues.apache.org/jira/browse/SANDBOX-510 > [2] Even though the names of the maven "modules" should > be changed (for the sake of code layout "standardization" > with other modular components such as "Commons RNG"). > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [crypto] New Release
The challenge is getting everything set up just right for building the various OS profiles. This component is quite different in this regard, getting help from the original contributors would be helpful. After much fiddling to install the proper packages, this builds OK: mvn package -DskipTests -P linux64 mvn package -DskipTests -P linux32 But these do not: mvn package -DskipTests -P win64 mvn package -DskipTests -P win32 due to: [INFO] --- maven-antrun-plugin:1.8:run (make) @ commons-crypto --- [INFO] Executing tasks make: [exec] make native CROSS_PREFIX=x86_64-w64-mingw32- OS_NAME=Windows OS_ARCH=x86_64 [exec] make[1]: Entering directory '/mnt/c/git/commons-crypto' [exec] x86_64-w64-mingw32-gcc -I"/usr/lib/jvm/java-1.8.0-openjdk-amd64/include" -I"/include" -Ilib/inc_win -O2 -fno-inline -Ilib/include -I/usr/include -I"src/main/native/org/apache/commons/crypto/" -I"/usr/lib/jvm/java-1.8.0-openjdk-amd64/include/linux" -I"target/jni-classes/org/apache/commons/crypto/cipher" -I"target/jni-classes/org/apache/commons/crypto/random" -c src/main/native/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.c -o target/commons-crypto-1.1.0-SNAPSHOT-Windows-x86_64/OpenSslCryptoRandomNative.o [exec] Makefile:54: recipe for target 'target/commons-crypto-1.1.0-SNAPSHOT-Windows-x86_64/OpenSslCryptoRandomNative.o' failed [exec] make[1]: Leaving directory '/mnt/c/git/commons-crypto' [exec] Makefile:82: recipe for target 'win64' failed [exec] In file included from src/main/native/org/apache/commons/crypto/random/org_apache_commons_crypto_random.h:22:0, [exec] from src/main/native/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.c:19: [exec] src/main/native/org/apache/commons/crypto/org_apache_commons_crypto.h:151:10: fatal error: Windows.h: No such file or directory [exec] #include [exec] ^~~ [exec] compilation terminated. [exec] make[1]: *** [target/commons-crypto-1.1.0-SNAPSHOT-Windows-x86_64/OpenSslCryptoRandomNative.o] Error 1 [exec] make: *** [win64] Error 2 [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 10.107 s [INFO] Finished at: 2020-06-13T13:58:50Z [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-antrun-plugin:1.8:run (make) on project commons-crypto: An Ant BuildException has occured: exec returned: 2 [ERROR] around Ant part .. @ 5:78 in /mnt/c/git/commons-crypto/target/antrun/build-make.xml I have: /mnt/c/git/commons-crypto# find /usr -name windows.h /usr/i686-w64-mingw32/include/windows.h /usr/share/mingw-w64/include/windows.h /usr/x86_64-w64-mingw32/include/windows.h Case matters here, so I wonder if the original others did not cross compile from Linux and instead built a little here, a little there, and so on. I can see "-Ilib/inc_win" in the build but I am not sure where that is supposed to be... Building with mac64 profile is no better: mvn package -DskipTests -P mac64 [INFO] --- maven-antrun-plugin:1.8:run (make) @ commons-crypto --- [INFO] Executing tasks make: [exec] make native OS_NAME=Mac OS_ARCH=x86_64 [exec] make[1]: Entering directory '/mnt/c/git/commons-crypto' [exec] gcc -arch x86_64 -Ilib/inc_mac -I"/usr/lib/jvm/java-1.8.0-openjdk-amd64/include" -O2 -fPIC -mmacosx-version-min=10.7 -fvisibility=hidden -I/usr/local/include -I/usr/local/opt/openssl/include -Ilib/include -I/usr/include -I"src/main/native/org/apache/commons/crypto/" -I"/usr/lib/jvm/java-1.8.0-openjdk-amd64/include/linux" -I"target/jni-classes/org/apache/commons/crypto/cipher" -I"target/jni-classes/org/apache/commons/crypto/random" -c src/main/native/org/apache/commons/crypto/random/OpenSslCryptoRandomNative.c -o target/commons-crypto-1.1.0-SNAPSHOT-Mac-x86_64/OpenSslCryptoRandomNative.o [exec] Makefile:54: recipe for target 'target/commons-crypto-1.1.0-SNAPSHOT-Mac-x86_64/OpenSslCryptoRandomNative.o' failed [exec] make[1]: Leaving directory '/mnt/c/git/commons-crypto' [exec] Makefile:88: recipe for target 'mac64' failed [exec] gcc: error: x86_64: No such file or directory [exec] gcc: error: unrecognized command line option ‘-arch’; did you mean ‘-march=’? [exec] gcc: error: unrecognized command line option ‘-mmacosx-version-min=10.7’ [exec] make[1]: *** [target/commons-crypto-1.1.0-SNAPSHOT-Mac-x86_64/OpenSslCryptoRandomNative.o] Error 1 [exec] make: *** [mac64] Error 2 [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 12.513 s [INFO] Finished at: 2020-06-13T14:08:40Z [INFO] [ERRO
Re: [Graph] Build fails (unit tests)
Hi. > You are welcome to implement your suggestion I want to, but this repo is out of my ability. Although I do have some experiences in ICPC, the graph part is handled by my team mates, and I personally nearly know nothing about any complex graph algorithms. Gilles Sadowski 于2020年6月13日周六 下午9:31写道： > Hi. > > 2020-06-13 15:11 UTC+02:00, Xeno Amess : > >> IMO, the top priority is now to fix the failing unit tests; > >> personally, I'm not going to merge any PR before that is > >> achieved (and please refer to the JIRA identifier[1] in the > >> corresponding commit/PR). > > > > agreed. > > > > And I still suggest revert back to the last version which can build, and > > start an investigation/modification about every commit after that. > > You are welcome to implement your suggestion and/or > coordinate with Amey. > > > After all it is not good to leave hundreds of commits who fails tests in > > branch master. > > That is confusing when people try to learn about history of this repo / > how > > does the repo built from beginning. > > Another perspective: It reflects the actual history of the > repository. > Presumably, this would not have happened in a released > component; at least, it was right for this component to be > in the sand-box. ;-) > > Personally, I'd forget about the history prior to the move to > git (viewed as the "initial" state from a source code donation), > fix the issues and start refactoring. > > Regards, > Gilles > > > > > Gilles Sadowski 于2020年6月13日周六 下午9:06写道： > > > >> Hello. > >> > >> After the migration from SVN to "gitbox", we noticed that the > >> _first_ build failed due to 3 unit tests not passing (see e.g. the > >> Travis report referred to the JIRA report[1]). > >> > >> The move to "git" was intended to make it easier for people > >> willing to revive the [Graph] project. > >> > >> IMO, the top priority is now to fix the failing unit tests; > >> personally, I'm not going to merge any PR before that is > >> achieved (and please refer to the JIRA identifier[1] in the > >> corresponding commit/PR). > >> > >> Furthermore, I'd suggest that branch "modularization" > >> becomes the reference branch (in place of "master"[2]), > >> since the latest batch of work for [Graph] was done on > >> that one, seemingly leaving "master" behind (TBC by > >> Amey?). [This path might avoid subsequent work of > >> merging the fixed (but outdated) "master" into the more > >> recent branch that is bound to replace it anyway...] > >> > >> Thanks, > >> Gilles > >> > >> [1] https://issues.apache.org/jira/browse/SANDBOX-510 > >> [2] Even though the names of the maven "modules" should > >> be changed (for the sake of code layout "standardization" > >> with other modular components such as "Commons RNG"). > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [Graph] Build fails (unit tests)
Hi. 2020-06-13 15:11 UTC+02:00, Xeno Amess : >> IMO, the top priority is now to fix the failing unit tests; >> personally, I'm not going to merge any PR before that is >> achieved (and please refer to the JIRA identifier[1] in the >> corresponding commit/PR). > > agreed. > > And I still suggest revert back to the last version which can build, and > start an investigation/modification about every commit after that. You are welcome to implement your suggestion and/or coordinate with Amey. > After all it is not good to leave hundreds of commits who fails tests in > branch master. > That is confusing when people try to learn about history of this repo / how > does the repo built from beginning. Another perspective: It reflects the actual history of the repository. Presumably, this would not have happened in a released component; at least, it was right for this component to be in the sand-box. ;-) Personally, I'd forget about the history prior to the move to git (viewed as the "initial" state from a source code donation), fix the issues and start refactoring. Regards, Gilles > > Gilles Sadowski 于2020年6月13日周六 下午9:06写道： > >> Hello. >> >> After the migration from SVN to "gitbox", we noticed that the >> _first_ build failed due to 3 unit tests not passing (see e.g. the >> Travis report referred to the JIRA report[1]). >> >> The move to "git" was intended to make it easier for people >> willing to revive the [Graph] project. >> >> IMO, the top priority is now to fix the failing unit tests; >> personally, I'm not going to merge any PR before that is >> achieved (and please refer to the JIRA identifier[1] in the >> corresponding commit/PR). >> >> Furthermore, I'd suggest that branch "modularization" >> becomes the reference branch (in place of "master"[2]), >> since the latest batch of work for [Graph] was done on >> that one, seemingly leaving "master" behind (TBC by >> Amey?). [This path might avoid subsequent work of >> merging the fixed (but outdated) "master" into the more >> recent branch that is bound to replace it anyway...] >> >> Thanks, >> Gilles >> >> [1] https://issues.apache.org/jira/browse/SANDBOX-510 >> [2] Even though the names of the maven "modules" should >> be changed (for the sake of code layout "standardization" >> with other modular components such as "Commons RNG"). - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Graph] Build fails (unit tests)
> IMO, the top priority is now to fix the failing unit tests; > personally, I'm not going to merge any PR before that is > achieved (and please refer to the JIRA identifier[1] in the > corresponding commit/PR). agreed. And I still suggest revert back to the last version which can build, and start an investigation/modification about every commit after that. After all it is not good to leave hundreds of commits who fails tests in branch master. That is confusing when people try to learn about history of this repo / how does the repo built from beginning. Gilles Sadowski 于2020年6月13日周六 下午9:06写道： > Hello. > > After the migration from SVN to "gitbox", we noticed that the > _first_ build failed due to 3 unit tests not passing (see e.g. the > Travis report referred to the JIRA report[1]). > > The move to "git" was intended to make it easier for people > willing to revive the [Graph] project. > > IMO, the top priority is now to fix the failing unit tests; > personally, I'm not going to merge any PR before that is > achieved (and please refer to the JIRA identifier[1] in the > corresponding commit/PR). > > Furthermore, I'd suggest that branch "modularization" > becomes the reference branch (in place of "master"[2]), > since the latest batch of work for [Graph] was done on > that one, seemingly leaving "master" behind (TBC by > Amey?). [This path might avoid subsequent work of > merging the fixed (but outdated) "master" into the more > recent branch that is bound to replace it anyway...] > > Thanks, > Gilles > > [1] https://issues.apache.org/jira/browse/SANDBOX-510 > [2] Even though the names of the maven "modules" should > be changed (for the sake of code layout "standardization" > with other modular components such as "Commons RNG"). > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
[Graph] Build fails (unit tests)
Hello. After the migration from SVN to "gitbox", we noticed that the _first_ build failed due to 3 unit tests not passing (see e.g. the Travis report referred to the JIRA report[1]). The move to "git" was intended to make it easier for people willing to revive the [Graph] project. IMO, the top priority is now to fix the failing unit tests; personally, I'm not going to merge any PR before that is achieved (and please refer to the JIRA identifier[1] in the corresponding commit/PR). Furthermore, I'd suggest that branch "modularization" becomes the reference branch (in place of "master"[2]), since the latest batch of work for [Graph] was done on that one, seemingly leaving "master" behind (TBC by Amey?). [This path might avoid subsequent work of merging the fixed (but outdated) "master" into the more recent branch that is bound to replace it anyway...] Thanks, Gilles [1] https://issues.apache.org/jira/browse/SANDBOX-510 [2] Even though the names of the maven "modules" should be changed (for the sake of code layout "standardization" with other modular components such as "Commons RNG"). - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Quick questions about this mailing list
On 13/06/2020 05:06, Miguel Munoz wrote: > When I send an email to this list, my email address shows up in the archive > as ending with .INVALID. Is there anything I can do about this? (I submitted > an ICLA, so that shouldn't be the problem.) https://blogs.apache.org/infra/entry/dmarc_filtering_on_lists_that Mark - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
