Problems building JFX media -help

Wed Jan 7 01:24:52 UTC 2015

I am trying to build JavaFX with native media enabled.  For background, 
read *The initial problem* below.

So I am stuck in build.gradle ( line 2392 for me)  in def buildGlib{ 
.... I have progressed somewhat since the initial problem.  To me it now 
seems that Gradle or Cywin or Make is messing up my Path so that the 
makefile is not able to execute lines like:
/MANIFEST   = $(shell cygpath -ma "$(BUILD_DIR)/$(BASE_NAME).manifest"/)
as it can't find cygpath.

I haven't fixed this yet, but I have some clues.
Firstly, I have added a line to the makefile (in 
E:\...\JavaFX\modules\media\src\main\native\gstreamer\projects\win\glib-lite/)  
a /lin/e SHELL=C:/cygwin/bin/sh.exe/to be sure I have a shell./
/Then I added a line to print the value of /PATH /in the makefile.
My DOS path (DOS SET PATH) has 26 items including C:\cygwin\bin; which 
is where cygpath.exe is held.
By the time /PATH /gets to the makefile it has 47 items and the item 
C:\cygwin\binhas been /replaced /by C:/cygwin64/bin;
As a result (I think) /$(shell cygpath/doesn't find cygpath and that 
breaks the build.

I have grepped for /cygwin64 /in the JFX tree but there are no hits.
So either Cygwin or Gradle or Cygwin-make is taking what may be a 
correct DOS path and making it into an incorrect path by the time it 
gets to /make/. /cygwin.bat/ does not do it. /mingw make 3.8/ has the 
same problem so perhaps it is in /Cygwin /or Gradle.

It seems /make /has a variable called PATH which is /derived /from DOS 
Path but is messed up.  DOS path itself is not changed.  I don't really 
understand who makes the make PATH or how /make /might use it in finding 
cygpath.exe.

But these are just clues.

Any ideas on where to look /what to do next?

Thanks

robinH

P.S.
It would be helpful if the page Building OpenJFX 
<https://wiki.openjdk.java.net/display/OpenJFX/Building+OpenJFX> was 
more specific about the versions of /Cygwin /& /make /which should be 
used as it is quite specific for most of the other tools. /Cygwin/make/ 
has been making changes in how they deal with DOS paths so perhaps they 
broke something.

------------------------------------------------- The initial probem 
-------------------------------------------------------------------------

I find JFX media HLS is not working well for me. It dies after about 30s 
whereas VLC can pick up the 'dead' m3u8 and continue playing fine, so I 
decided to build from source to try to see what is going on.  I have 
followed Michael Berry's efforts extending media codecs too. Also,  I 
found this 
<https://coaxion.net/blog/2014/05/http-adaptive-streaming-with-gstreamer/>(November 
26, 2014 at 15:04 
<https://coaxion.net/blog/2014/05/http-adaptive-streaming-with-gstreamer/comment-page-1/#comment-28467>) 
comment interesting in response to the question "Is there any support on 
gstreamer 0.10 for Adaptive Streaming – Smooth Streaming, Dash etc. ?" . 
'Slomo' replied /"There is some initial support for HLS but don’t use 
0.10 for anything really. It’s no longer maintained since more than 2 
years and a lot has happened since then"/. The rest of his blog ('*HTTP 
Adaptive Streaming with GStreamer*') seemed to indicate he had some 
knowledge in this area.  So I decided to build from source to see more 
of what is going on.

I chose to build 8u-dev/rt from Hg, although that may not have been the 
best choice.
The initial build went fine (without native).  It was */easy/*. 
Congratulations!

Then I made a gradle.properties and set COMPILE_MEDIA = true and got 
errors.  These are in of build.gradle ( line 2392 for me)  in def 
buildGlib{ ....
This exec's the makefile in 
E:\robins_root\software\JavaFX\modules\media\src\main\native\gstreamer\projects\win\glib-lite.
The errors look like:
/bin/sh: cygpath: command not found
/    Makefile:71: recipe for target '/libglib-2.28.8.lib' failed/ /( I 
have messed up the line numbers ignore 71)/
And make returns 2 and error 127.  Now from the cywin window, I can do

/Robin at MY-PC /cygdrive/e/robins_root/software/JavaFX//
//$ cygpath --help//
//cygpath --help//
//Usage: cygpath (-d|-m|-u|-w|-t TYPE) [-f FILE] [OPTION]... NAME.../
etc
and also
/$ echo $SHELL//
//echo $SHELL//
//C:\cygwin\bin\bash.exe/
and echo path starts off
/usr/local/bin:
/usr/bin:
/cygdrive/c/ProgramData/Oracle/Java/javapath:
/cygdrive/c/Tcl/bin:
/cygdrive/c/Windows/system32:
/cygdrive/c/Windows:
...
If I manually run the makefile from its folder, fixing up any needed 
variables, it seemed to run OK.  ( Although my VS2010 was initially 
damaged. I had to set up the INCLUDE environment variable since I was 
getting windows.h not found.  I think this is caused somehow by having 
VS2010, VS2011 & VS2012 originally, then removing all three and doing a 
clean install of VS2010. I googled reports of others having this problem 
of corrupted include path.)

My installation is unusual (?) in that all my JFX builder folders are on 
e: whereas Cywgin is on c:  .  I need to use both paths /cygdrive/e/ 
and  /cygdrive/c/.

The detailed build instructions are detailed about versions for most 
programs, but not for cygwin & make. I wonder which version you use in 
your builds?

Does Gradle change the SHELL variable?  Does Gradle/cygwin/make assume 
all programs are on say a C: drive?  mintty has no problem finding 
cygpath.  Is Gradle looking for cygpath on e: instead of c:?

Now I have been playing with PATH & SHELL but nothing I do seems to help.

Any suggestions?

---------------------------------------------------------------------------
I am using:
Gradle 1.8   Build time: 2013-09-24 07:32:33 UTC  Revision: 
7970ec3503b4f5767ee1c1c69f8b4186c4763e3d  Groovy:1.8.6
Ant:          Apache Ant(TM) version 1.9.2 compiled on July 8 2013
Ivy:          2.2.0
JVM:          1.8.0_05 (Oracle Corporation 25.5-b02)
OS:           Windows 8.1 6.3 x86
$uname -a   CYGWIN_NT-6.3-WOW64 ROBIN-PC 1.7.33-2(0.280/5/3) 2014-11-13 
15:45 i686 Cygwin
make -v   GNU Make 4.0  Built for i686-pc-cygwin
cygwin install, version 2.859
I used CygWin setup-x86.exe so I presume this is 32-bit Cygwin
JAVA_HOME points to (X86) jdk1.8.0.05
JRE_HOME  (X86) jre8
My machine also has 64-bit jdk1.8.0_25 & jdk1.8.0_05in Program Files