Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ocamlc -where, camlp4 -where, etc. add \r\n on mingw #4957

Closed
vicuna opened this issue Jan 10, 2010 · 9 comments
Closed

ocamlc -where, camlp4 -where, etc. add \r\n on mingw #4957

vicuna opened this issue Jan 10, 2010 · 9 comments

Comments

@vicuna
Copy link

vicuna commented Jan 10, 2010

Original bug ID: 4957
Reporter: matt
Status: resolved (set by @xavierleroy on 2017-10-15T14:18:18Z)
Resolution: won't fix
Priority: normal
Severity: minor
Category: platform support (windows, cross-compilation, etc)
Related to: #7116
Monitored by: @ygrek

Bug description

I may be wrong, but I would find it easier to use if the eol of the string returned by ocamlc -where etc. was \n, not \r\n

A lot of installers are broken or partially broken because of this.

Salutations.

@vicuna
Copy link
Author

vicuna commented Jan 11, 2010

Comment author: @ygrek

Also keeping only forward slashes in these paths will make the life simpler. Currently there is the mix of forward and backslashes (msvc target).

@vicuna
Copy link
Author

vicuna commented Dec 15, 2011

Comment author: matt

The problem is with mingw flavour of the distribution. Usually, it is used with "unix" tools (ocamlbuild, cygwin, …), while msvc flavour tend to use more "win" tools.

OCaml tools should be able to distinguish between msvc and mingw flavour, I would say, in order to adapt their ouptputs. I don't know if it is currently possible?

I'm aware of Sys.os_type. But it seems not enough detailed to me.
"Win32" is used both for mingw and MSVC.

Modifying Sys.os_type would break a lot of code. Maybe adding: Sys.os_flavour with more detailed information (mingw, msvc, unix, osx, …) would be a good first step?

@vicuna
Copy link
Author

vicuna commented Dec 15, 2011

Comment author: ripoche

+1 for slashes in paths, even for msvc.

@vicuna
Copy link
Author

vicuna commented Sep 10, 2012

Comment author: meyer

I raise the severity to major as it breaks the installers. I think it would be sensible to expect from mingw port to return Unix style EOL delimiters.

However I think we don't expect it to fix it before 4.00.2, if you think it's a showstopper then please do let us know promptly, thanks.

@vicuna
Copy link
Author

vicuna commented Jan 15, 2013

Comment author: @alainfrisch

I'm not sure that the mingw and the msvc should behave differently. I understand that the current situation can break installers, but why is it specific to the mingw port? It makes perfect sense to use the msvc port even e.g. from Cygwin.

@vicuna
Copy link
Author

vicuna commented Dec 11, 2015

Comment author: @xavierleroy

I don't see what we could do here that would not be horribly ad-hoc. Owing to OCaml's bootstrapped nature, the mingw and msvc ports of OCaml both generate pure Win32 executables and are themselves pure Win32 executables. When they print something on standard output, it undergoes end-of-line conversion just like with all pure Win32 programs.

Concerning "breaking the installers": isn't ocamlfind the preferred way to install these days? and does it also suffer from this end-of-line issue?

@vicuna
Copy link
Author

vicuna commented Apr 19, 2016

Comment author: @damiendoligez

One possible solution would be to not output any NL at the end of ocamlc -where. Since it is most likely to be used in a shell script between backquotes, there isn't really a need for the NL character(s).

For interactive use, the absence of NL would be at most a minor inconvenience.

@vicuna
Copy link
Author

vicuna commented Oct 12, 2017

Comment author: @dra27

Especially now that the Cygwin tools are completely unforgiving of \r, meaning that output of any non-Cygwin command must be post-processed (e.g. with tr -d '\r'), I'd move to mark this as "won't fix"

I've added a relationship to #7116 - one of the suggestions there is to introduce -config-key or -config-var which would return the value of a specific configuration item, expressly for use in scripts and so-forth. I would agree that that command should not output any \r or \n at the end of the value it returns.

@vicuna
Copy link
Author

vicuna commented Oct 15, 2017

Comment author: @xavierleroy

I agree with @dra's analysis. Marking as resolved/won't fix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant