Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0004957OCamlplatform support (windows, cross-compilation, etc)public2010-01-10 18:112017-10-15 16:18
Assigned To 
StatusresolvedResolutionwon't fix 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0004957: ocamlc -where, camlp4 -where, etc. add \r\n on mingw
DescriptionI 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.

TagsNo tags attached.
Attached Files

- Relationships
related to 0007116feedback Allow easy retrieval of Makefile.config's values 

-  Notes
ygrek (reporter)
2010-01-11 11:07

Also keeping only forward slashes in these paths will make the life simpler. Currently there is the mix of forward and backslashes (msvc target).
matt (reporter)
2011-12-15 10:03

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?
ripoche (reporter)
2011-12-15 10:57

+1 for slashes in paths, even for msvc.
meyer (developer)
2012-09-10 05:09

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.
frisch (developer)
2013-01-15 14:31

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.
xleroy (administrator)
2015-12-11 17:17

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?
doligez (administrator)
2016-04-19 14:23

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.
dra (developer)
2017-10-12 14:44

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 MPR#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.
xleroy (administrator)
2017-10-15 16:18

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

- Issue History
Date Modified Username Field Change
2010-01-10 18:11 matt New Issue
2010-01-11 11:07 ygrek Note Added: 0005226
2011-05-31 16:42 doligez Status new => acknowledged
2011-12-15 10:03 matt Note Added: 0006305
2011-12-15 10:57 ripoche Note Added: 0006307
2012-07-11 13:32 doligez Target Version => 4.01.0+dev
2012-07-31 13:36 doligez Target Version 4.01.0+dev => 4.00.1+dev
2012-09-10 05:09 meyer Note Added: 0008041
2012-09-10 05:09 meyer Severity minor => major
2012-09-10 05:09 meyer Target Version 4.00.1+dev => 4.00.2+dev
2013-01-15 14:31 frisch Note Added: 0008756
2013-06-06 23:08 frisch Severity major => minor
2013-06-06 23:08 frisch Target Version 4.00.2+dev => 4.02.0+dev
2013-07-12 18:15 doligez Target Version 4.02.0+dev => 4.01.1+dev
2014-05-25 20:20 doligez Target Version 4.01.1+dev => 4.02.0+dev
2014-07-31 15:59 doligez Target Version 4.02.0+dev => 4.02.1+dev
2014-09-04 00:25 doligez Target Version 4.02.1+dev => undecided
2014-09-26 17:46 doligez Target Version undecided => 4.02.2+dev / +rc1
2015-03-18 17:53 frisch Target Version 4.02.2+dev / +rc1 => 4.03.0+dev / +beta1
2015-12-11 17:17 xleroy Note Added: 0015133
2016-04-19 14:23 doligez Note Added: 0015812
2016-04-19 14:25 doligez Target Version 4.03.0+dev / +beta1 => 4.03.1+dev
2016-12-08 16:34 shinwell Category OCaml general => OCaml windows
2017-02-16 14:00 doligez Target Version 4.03.1+dev => undecided
2017-02-23 16:46 doligez Category OCaml windows => platform support (windows, etc)
2017-02-23 17:16 doligez Category platform support (windows, etc) => platform support (windows, cross-compilation, etc)
2017-03-15 11:13 doligez Target Version undecided =>
2017-10-12 14:41 dra Relationship added related to 0007116
2017-10-12 14:44 dra Note Added: 0018546
2017-10-15 16:18 xleroy Note Added: 0018568
2017-10-15 16:18 xleroy Status acknowledged => resolved
2017-10-15 16:18 xleroy Resolution open => won't fix

Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker