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

Better descriptions (and export parameters) around the dependency generator for OCaml #7576

Closed
vicuna opened this issue Jul 1, 2017 · 8 comments

Comments

@vicuna
Copy link

vicuna commented Jul 1, 2017

Original bug ID: 7576
Reporter: @elfring
Status: closed (set by @xavierleroy on 2017-07-21T15:29:17Z)
Resolution: not a bug
Priority: normal
Severity: feature
Version: 4.03.0
Category: tools (ocaml{lex,yacc,dep,debug,...})
Related to: #7558

Bug description

The documentation contains the following information:
“…
The typical usage is:

   ocamldep options *.mli *.ml > .depend

…”

I find that there are more details worth for further software development considerations around such an example.

  1. It will be sufficient to refer to a single source file directory in some use cases.

  2. But I imagine that this interface should also work to some degree when file names are passed as a mixture from several directories.
    How good can OCaml module references be mapped to paths in the file system then?

  3. Will it be safer to store the generated dependency file (or the provided data generally) at an other place (than within the same folder)?

Additional information

https://caml.inria.fr/pub/docs/manual-ocaml/depend.html

Support selection of source file names also for other export formats than make rules
#7558

@vicuna
Copy link
Author

vicuna commented Jul 1, 2017

Comment author: @dra27

Please stop spamming this bug-tracker with incomplete or non-reports! As a rule of thumb, if you are categorising something as severity "feature", but your report includes question marks, then it should not be here.

If, having found the answers to your two questions above somewhere else, you find you would still like the example in the manual to be "improved", you may either come back to Mantis with a concrete suggestion or submit a pull request for it (the particular file is https://github.com/ocaml/ocaml/blob/trunk/manual/manual/cmds/depend.etex).

@vicuna
Copy link
Author

vicuna commented Jul 1, 2017

Comment author: @elfring

I proposed to make another information source a bit better.
Do you care for unwanted consequences from a questionable documentation quality?

I try to check also the general change acceptance before I offer a special pull request for a registered issue.

@vicuna
Copy link
Author

vicuna commented Jul 2, 2017

Comment author: @elfring

How can be achieved that only directories will be exported from the passed filenames in the order in which the specified software components depend on each other?

@vicuna
Copy link
Author

vicuna commented Jul 3, 2017

Comment author: @dra27

You haven't yet demonstrated an improvement to the documentation, and you ask questions the answers for which you should determine elsewhere before logging feature requests here.

@vicuna
Copy link
Author

vicuna commented Jul 3, 2017

Comment author: @elfring

It seems that we prefer different communication styles for this issue.

I request a data export of directories which are referenced by the specified OCaml source files.
Please use the command parameter “-rd” (or the long option “--referenced-directories”) for this purpose.

@vicuna
Copy link
Author

vicuna commented Jul 21, 2017

Comment author: @xavierleroy

Enough with the reopening games.

@elfring
Copy link

elfring commented Apr 15, 2019

Will other contributors dare to continue the clarification of affected software components?

@dra27
Copy link
Member

dra27 commented Apr 15, 2019

They appear to have continued to since 2017, yes.

@ocaml ocaml locked as off-topic and limited conversation to collaborators Apr 15, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants