yochju / latex-makefile

Automatically exported from code.google.com/p/latex-makefile
Other
0 stars 0 forks source link

no more usable on cygwin with make 3.81 #112

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago
I did try it on cygwin and it worked great. I've recently installed a new 
machine with the latest cygwin and try to use latex-makefile on it and got the 
error like

recovery.d:3: *** target pattern contains no `%'.  Stop.

This apparently is because that Make no more accepts windows path.
while the content of recovery.d is

# vim: ft=make
.PHONY: recovery._graphics
recovery.aux recovery.aux.make recovery.d recovery.pdf: C:/Program\ 
Files/MiKTeX\ 2.9/tex/latex/base/article.cls
recovery.aux recovery.aux.make recovery.d recovery.pdf: C:/Program\ 
Files/MiKTeX\ 2.9/tex/latex/base/fontenc.sty
recovery.aux recovery.aux.make recovery.d recovery.pdf: C:/Program\ 
Files/MiKTeX\ 2.9/tex/latex/base/inputenc.sty
recovery.aux recovery.aux.make recovery.d recovery.pdf: C:/Program\ 
Files/MiKTeX\ 2.9/tex/latex/fancyhdr/fancyhdr.sty
recovery.aux recovery.aux.make recovery.d recovery.pdf: C:/Program\ 
Files/MiKTeX\ 2.9/tex/latex/graphics/color.sty
recovery.aux recovery.aux.make recovery.d recovery.pdf: C:/Program\ 
Files/MiKTeX\ 2.9/tex/latex/psnfss/times.sty
recovery.aux recovery.aux.make recovery.d recovery.pdf: 
E:/clean/Docs/Devel/recovery.tex
.SECONDEXPANSION:

Is it possible for latex-makefile to use posix file names every where on cygwin 
or it is an issue of make/cygwin?

Thanks in advance!

Original issue reported on code.google.com by xuewen.w...@gmail.com on 1 Feb 2011 at 2:40

GoogleCodeExporter commented 9 years ago
These filenames are coming straight from your latex binary.  If you were to 
just go to your directory and run

pdflatex -recorder -interaction=batchmode recovery

and then to do

cat recorder.fls

You would find that those path names are coming from that file.  So, I can't 
change the way that your latex is outputting file paths.  It looks like this is 
not a cygwin problem, but is rather due to a change in your tex distribution.  
Does that sound right to you?

Original comment by shiblon on 1 Feb 2011 at 4:15

GoogleCodeExporter commented 9 years ago
You are right. I've changed to use MiKTex which is a native windows 
implementation of tex. So this is not really a latex-makefile issue. Thanks for 
the hint.

So you may just close the issue as invalid. I would just like to know if you 
can tell me the place in the Makegile that I can insert call to cygpath to 
convert the path generated by MiKTex to cygwin path.

Thanks again!

Original comment by xuewen.w...@gmail.com on 1 Feb 2011 at 4:28

GoogleCodeExporter commented 9 years ago
I hadn't heard of cygpath before today.  How does it work?

We can probably fix this in the makefile, or at least provide a usable 
workaround.

Original comment by shiblon on 1 Feb 2011 at 4:35

GoogleCodeExporter commented 9 years ago
cygpath is a cygwin program to convert windows native path to cygwin path.

For example:

cygpath -u "C:/Program Files/MiKTeX 2.9/fonts/type1/urw/times/utmr8a.pfb"
will return
/cygdrive/c/Program Files/MiKTeX 2.9/fonts/type1/urw/times/utmr8a.pfb

If you can fix this in the makefile, that would be great since MiKTex is much 
easier to use and more up to date than tetex packaged in cygwin which is no 
more actively maintained (and replaced by texlive in upstream).

Original comment by xuewen.w...@gmail.com on 1 Feb 2011 at 4:46

GoogleCodeExporter commented 9 years ago
OK - let's try this by hand and see if it works.

After generating your recovery.d file, open it up and do the following:

- move ".SECONDEXPANSION" to the top fo the file, just under the #vim comment

- Change every line to call cygpath.  An example is given below:

recovery.aux recovery.aux.make recovery.d recovery.pdf: $$(shell cygpath -u 
"C:/Program Files/MikTex 2.9/tex/latex/base/article.cls")

If that works, we're set.  I suspect that it won't, though, because we still 
have a colon parsing issue.  Nevertheless, I'm really hoping that does it.

Original comment by shiblon on 1 Feb 2011 at 4:55

GoogleCodeExporter commented 9 years ago
OK. I've replaced recovery.d with the following:

# vim: ft=make
.SECONDEXPANSION:
.PHONY: recovery._graphics
recovery.aux recovery.aux.make recovery.d recovery.pdf: $(shell cygpath -u 
"$(shell cygpath -s -w C:/Program\ Files/MiKTeX\ 
2.9/tex/latex/base/article.cls)")
recovery.aux recovery.aux.make recovery.d recovery.pdf: $(shell cygpath -u 
"$(shell cygpath -s -w C:/Program\ Files/MiKTeX\ 
2.9/tex/latex/base/fontenc.sty)")
recovery.aux recovery.aux.make recovery.d recovery.pdf: $(shell cygpath -u 
"$(shell cygpath -s -w C:/Program\ Files/MiKTeX\ 
2.9/tex/latex/base/inputenc.sty)")
recovery.aux recovery.aux.make recovery.d recovery.pdf: $(shell cygpath -u 
"$(shell cygpath -s -w C:/Program\ Files/MiKTeX\ 
2.9/tex/latex/fancyhdr/fancyhdr.sty)")
recovery.aux recovery.aux.make recovery.d recovery.pdf: $(shell cygpath -u 
"$(shell cygpath -s -w C:/Program\ Files/MiKTeX\ 
2.9/tex/latex/graphics/color.sty)")
recovery.aux recovery.aux.make recovery.d recovery.pdf: $(shell cygpath -u 
"$(shell cygpath -s -w C:/Program\ Files/MiKTeX\ 
2.9/tex/latex/psnfss/times.sty)")
recovery.aux recovery.aux.make recovery.d recovery.pdf: $(shell cygpath -u 
"$(shell cygpath -s -w E:/clean/Docs/Devel/recovery.tex)")

Due to the space inside the directory name, I have to convert at first the 
windows path to dos 8.3 format and then use cygpath -u.

It seems that it does produce the necessary recovery.pdf without error. So 
there may have a chance that you can fix this in the makefile!

Thanks in advance!

Original comment by xuewen.w...@gmail.com on 1 Feb 2011 at 5:35

GoogleCodeExporter commented 9 years ago
OK - one last question.

Does it work if you do the following?

# vim: ft=make
do-cygpath = $(shell cygpath -u $(shell cygpath -s -w "$1"))
.PHONY: recovery._graphics
recovery.aux recovery.aux.make recovery.d recovery.pdf: $(call 
do-cygpath,C:/Program\ Files/MiKTeX\ 2.9/tex/latex/base/article.cls)
recovery.aux recovery.aux.make recovery.d recovery.pdf: $(call 
do-cygpath,C:/Program\ Files/MiKTeX\ 2.9/tex/latex/base/fontenc.sty)
recovery.aux recovery.aux.make recovery.d recovery.pdf: $(call 
do-cygpath,C:/Program\ Files/MiKTeX\ 2.9/tex/latex/base/inputenc.sty)
recovery.aux recovery.aux.make recovery.d recovery.pdf: $(call 
do-cygpath,C:/Program\ Files/MiKTeX\ 2.9/tex/latex/fancyhdr/fancyhdr.sty)
recovery.aux recovery.aux.make recovery.d recovery.pdf: $(call 
do-cygpath,C:/Program\ Files/MiKTeX\ 2.9/tex/latex/graphics/color.sty)
recovery.aux recovery.aux.make recovery.d recovery.pdf: $(call 
do-cygpath,C:/Program\ Files/MiKTeX\ 2.9/tex/latex/psnfss/times.sty)
recovery.aux recovery.aux.make recovery.d recovery.pdf: $(call 
do-cygpath,E:/clean/Docs/Devel/recovery.tex)
.SECONDEXPANSION

Original comment by shiblon on 1 Feb 2011 at 6:38

GoogleCodeExporter commented 9 years ago
Unfortunately, using do-cygpath doesn't work, and gave error like:

cygpath: cannot create short name of C:\Program\ Files\MiKTeX\ 
2.9\tex\latex\base\article.cls
Usage: cygpath (-d|-m|-u|-w|-t TYPE) [-f FILE] [OPTION]... NAME...
       cygpath [-c HANDLE] 
       cygpath [-ADHOPSW] 
       cygpath [-F ID] 
Convert Unix and Windows format paths, or output system path information

Output type options:
  -d, --dos             print DOS (short) form of NAMEs (C:\PROGRA~1\)
  -m, --mixed           like --windows, but with regular slashes (C:/WINNT)
  -M, --mode            report on mode of file (binmode or textmode)
  -u, --unix            (default) print Unix form of NAMEs (/cygdrive/c/winnt)
  -w, --windows         print Windows form of NAMEs (C:\WINNT)
  -t, --type TYPE       print TYPE form: 'dos', 'mixed', 'unix', or 'windows'
Path conversion options:
  -a, --absolute        output absolute path
  -l, --long-name       print Windows long form of NAMEs (with -w, -m only)
  -p, --path            NAME is a PATH list (i.e., '/bin:/usr/bin')
  -s, --short-name      print DOS (short) form of NAMEs (with -w, -m only)
  -C, --codepage CP     print DOS, Windows, or mixed pathname in Windows
                        codepage CP.  CP can be a numeric codepage identifier,
                        or one of the reserved words ANSI, OEM, or UTF8.
                        If this option is missing, cygpath defaults to the
                        character set defined by the current locale.
System information:
  -A, --allusers        use `All Users' instead of current user for -D, -O, -P
  -D, --desktop         output `Desktop' directory and exit
  -H, --homeroot        output `Profiles' directory (home root) and exit
  -O, --mydocs          output `My Documents' directory and exit
  -P, --smprograms      output Start Menu `Programs' directory and exit
  -S, --sysdir          output system directory and exit
  -W, --windir          output `Windows' directory and exit
  -F, --folder ID       output special folder with numeric ID and exit
Try `cygpath --help' for more information.

It seems that there is quoting issue. I'm sorry that I don't know enough shell 
to understand how to fix it  but indeed defining a function can simplify the 
code a lot.

Original comment by xuewen.w...@gmail.com on 1 Feb 2011 at 8:48

GoogleCodeExporter commented 9 years ago
Interesting.  What if the function is defined differently (without quotes):

do-cygpath = $(shell cygpath -u $(shell cygpath -s -w $1))

Original comment by shiblon on 1 Feb 2011 at 8:55

GoogleCodeExporter commented 9 years ago
Without quotes, I got the same error as from the beginning:

recovery.d:4: *** target pattern contains no `%'.  Stop.

Original comment by xuewen.w...@gmail.com on 1 Feb 2011 at 9:09

GoogleCodeExporter commented 9 years ago
Oh, of course!

But, interestingly, if I understood the one working fix properly, it looks like 
you can do this:

do-cygpath = $(shell cygpath -u "$(shell cygpath -s -w $1)")

If that doesn't work, it's back to the drawing board.  Also, the 
.SECONDEXPANSION may actually be necessary at the top of the file, there.  I 
wasn't sure whether it was needed or not, but it very well may be.

Original comment by shiblon on 2 Feb 2011 at 9:17

GoogleCodeExporter commented 9 years ago
OK. The following works:

# vim: ft=make
do-cygpath = $(shell cygpath -u "$(shell cygpath -s -w $1)")
.SECONDEXPANSION:
.PHONY: recovery._graphics
recovery.aux recovery.aux.make recovery.d recovery.pdf: $(call 
do-cygpath,C:/Program\ Files/MiKTeX\ 2.9/tex/latex/base/article.cls)
recovery.aux recovery.aux.make recovery.d recovery.pdf: $(call 
do-cygpath,C:/Program\ Files/MiKTeX\ 2.9/tex/latex/base/fontenc.sty)
recovery.aux recovery.aux.make recovery.d recovery.pdf: $(call 
do-cygpath,C:/Program\ Files/MiKTeX\ 2.9/tex/latex/base/inputenc.sty)
recovery.aux recovery.aux.make recovery.d recovery.pdf: $(call 
do-cygpath,C:/Program\ Files/MiKTeX\ 2.9/tex/latex/fancyhdr/fancyhdr.sty)
recovery.aux recovery.aux.make recovery.d recovery.pdf: $(call 
do-cygpath,C:/Program\ Files/MiKTeX\ 2.9/tex/latex/graphics/color.sty)
recovery.aux recovery.aux.make recovery.d recovery.pdf: $(call 
do-cygpath,C:/Program\ Files/MiKTeX\ 2.9/tex/latex/psnfss/times.sty)
recovery.aux recovery.aux.make recovery.d recovery.pdf: $(call 
do-cygpath,E:/clean/Docs/Devel/recovery.tex)

Original comment by xuewen.w...@gmail.com on 3 Feb 2011 at 9:01

GoogleCodeExporter commented 9 years ago
Thanks - I'll see what I can do with this.  I think I'll have a variable that 
you can set to do path manipulation.  Or I could check for the presence of the 
cygpath binary and use it if it's there....  What do you think would be best?

Also, if you remove .SECONDEXPANSION, does the above still work?

Original comment by shiblon on 3 Feb 2011 at 3:22

GoogleCodeExporter commented 9 years ago
It seems that it works even if I remove .SECONDEXPANSION.

Actually, even if on cygwin, if one is using the latex from the cygwin package, 
no path manipulation is needed. It is only when the makefile is used on cygwin 
with native windows tex implementation like MiKTex that doesn't work. It is 
possible to check this particular case automatically, but a variable to set for 
path manipulation works also for me.

Thanks in advance!

Original comment by xuewen.w...@gmail.com on 3 Feb 2011 at 3:37

GoogleCodeExporter commented 9 years ago
And thanks for your patience as we try to find the right answer here :)

You mention that it is possible for us to check for miktex and do this 
automatically - if that's the case, I would much prefer it, since one of the 
goals of the makefile is that it require no fiddling to make it work for most 
cases.

I'm assuming that calling cygpath within cygwin on a standard unix-like 
pathname does nothing?  If so, then I can just call cygpath if it exists, and 
not call it if it doesn't....

Original comment by shiblon on 3 Feb 2011 at 4:01

GoogleCodeExporter commented 9 years ago
If MikTex can be automatically detected and then cygpath called properly on 
path returned by MiKTex, that would be the best solution.

cygpath -u called on unix path doesn't change it.

Thanks!

Original comment by xuewen.w...@gmail.com on 3 Feb 2011 at 4:08

GoogleCodeExporter commented 9 years ago
rbe8fd3c38afd contains the fix, and I've attached the generated makefile here.  
Give it a try, and let me know how it works for you.

Original comment by shiblon on 3 Feb 2011 at 4:20

Attachments:

GoogleCodeExporter commented 9 years ago
Just did a quick test and it works! Thanks for the quick fix!

Original comment by xuewen.w...@gmail.com on 3 Feb 2011 at 4:45

GoogleCodeExporter commented 9 years ago
Glad it worked for you!

Original comment by shiblon on 3 Feb 2011 at 5:30

GoogleCodeExporter commented 9 years ago
This fix has introduced a regression for my configuration. I've verified that 
rc9 works for me, but rc10 does not. The makefile works as normal, but now it 
spits out this error after every invocation: 

which: no cygpath in 
(/usr/local/lf6480/bin:/auto/users/foo/local/jre1.6.0_21/bin:~/src/:/auto/users/
foo/local/texlive/2010/bin/x86_64-linux:/auto/users/foo/local/bin:/usr/kerberos/
bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/opt/pathscale/bin:/auto/share/b
in)

Original comment by onion.av...@gmail.com on 2 Mar 2011 at 5:33

GoogleCodeExporter commented 9 years ago
Sorry, I forgot to state that I'm running Linux (RHEL4) so I don't use cygwin.

Original comment by onion.av...@gmail.com on 2 Mar 2011 at 5:33

GoogleCodeExporter commented 9 years ago
I'm looking at this now.

Original comment by shiblon on 2 Mar 2011 at 8:06

GoogleCodeExporter commented 9 years ago
Try the attached -let me know if it works for you.

Original comment by shiblon on 2 Mar 2011 at 8:08

Attachments:

GoogleCodeExporter commented 9 years ago
Yup, that works. Thanks!

Original comment by onion.av...@gmail.com on 2 Mar 2011 at 9:22

GoogleCodeExporter commented 9 years ago
Closing out again and uploading version 2.2.0-rc11

Original comment by shiblon on 3 Mar 2011 at 4:09

GoogleCodeExporter commented 9 years ago
I had few more problems with make 3.81 on cygwin.

USE_CYGPATH was not set, so I changed it to use uname -o

The bib-file needed also to be passed through path-norm, so I added this to 
get-bibs

Patch attached, seems to work for me

Original comment by ferr...@gmail.com on 7 Mar 2011 at 9:03

Attachments:

GoogleCodeExporter commented 9 years ago
Before I apply this, I just want to make sure that I understand what is broken 
about the old approach.

It looks like I made the classic mistake of diverting both stdout and stderr to 
/dev/null, instead of just one of them.  So, I believe that you can get the 
USE_CYGPATH working properly by changing it to the following:

USE_CYGPATH := $(if $(shell $(WHICH) $(CYGPATH) 2>/dev/null),yes,)

Can you check that the above works?

The bib changes are useful.  I wonder what else we might have missed....

Original comment by shiblon on 9 Mar 2011 at 9:35

GoogleCodeExporter commented 9 years ago
Oops - marking Open.

So, two problems:

1) fix USE_CYGPATH
2) fix bib files to undergo path normalization.

Original comment by shiblon on 9 Mar 2011 at 9:36

GoogleCodeExporter commented 9 years ago
By the way, the sed fix won't work properly unless cygpath returns multiple 
outputs, one for each input.  Additionally, if we're going to edit the sed 
script, we want to do it on the line before s!^!$2: !, not the line after.  I 
don't have anywhere to run cygpath to test how it works, so it would be nice to 
verify that calling it this way does the right thing:

cygpath C:\dir1\file1.txt C:\dir2\file2.txt

Ideally, it will convert all of its arguments and generate one filename each.  
If not, I need to think carefully about how to make it work properly, probably 
using a shell loop.

Original comment by shiblon on 9 Mar 2011 at 9:42

GoogleCodeExporter commented 9 years ago
Where did we end up here?

Original comment by shiblon on 22 Apr 2011 at 3:47

GoogleCodeExporter commented 9 years ago
cygpath "C:\dir1\file1.txt" "C:\dir2\file2.txt" returns
/cygdrive/c/dir1/file1.txt
/cygdrive/c/dir2/file2.txt

For me. It seems that it works as you expected :)

Original comment by xuewen.w...@gmail.com on 22 Apr 2011 at 4:03

GoogleCodeExporter commented 9 years ago
OK - sorry I'm so slow.  Yes, that's exactly what I hoped it would do.

So, just to refresh my leaky memory, what remains is to just apply your patch?

Original comment by shiblon on 9 May 2011 at 8:27

GoogleCodeExporter commented 9 years ago
Give the attached version a try and let me know how it works.  Relevant changes 
in r74fed3f4dd3c.

Original comment by shiblon on 9 May 2011 at 8:40

Attachments:

GoogleCodeExporter commented 9 years ago
Were you able to try the attachment to see if it works properly?  I'd love to 
know how it's going for you.

Original comment by shiblon on 14 Jun 2011 at 3:52