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

tag does not expect a parameter, but is used with parameter ... #5406

Closed
vicuna opened this issue Nov 22, 2011 · 10 comments
Closed

tag does not expect a parameter, but is used with parameter ... #5406

vicuna opened this issue Nov 22, 2011 · 10 comments

Comments

@vicuna
Copy link

vicuna commented Nov 22, 2011

Original bug ID: 5406
Reporter: william
Assigned to: @gasche
Status: closed (set by @xavierleroy on 2016-12-07T10:34:30Z)
Resolution: fixed
Priority: normal
Severity: minor
Version: 3.12.0
Target version: 4.02.0+dev
Fixed in version: 4.02.0+dev
Category: -for ocamlbuild use https://github.com/ocaml/ocamlbuild/issues
Tags: junior_job
Related to: #5547
Monitored by: mehdi @ygrek @hcarty

Bug description

ocamlbuild warns for something strange. For example :

ocamlbuild -pkgs lablgtk2 -tags warn_s tree.byte

Warning: tag "package" does not expect a parameter, but is used with parameter "lablgtk2"
Finished, 3 targets (0 cached) in 00:00:00.

Attached is file tree.ml taken from lablgtk2

File attachments

@vicuna
Copy link
Author

vicuna commented Nov 23, 2011

Comment author: @xclerc

This is not really a bug; if you use any ocamlfind feature,
you should pass the "-use-ocamlfind" command-line
switch to ocamlbuild. It will make the warning disappear.

@vicuna
Copy link
Author

vicuna commented Nov 26, 2011

Comment author: william

ok that works. But we are not supposed to know that using "pkgs" option also requires "use-ocamlfind" option. If "pkgs" is an ocamlfind feature, then why not activate "use-ocamlfind" at the same time? Or why not activate ocamlfind all the time?

@vicuna
Copy link
Author

vicuna commented Nov 28, 2011

Comment author: @ygrek

or make the warning say what it means. I.e. when tag with unexpected parameter is "package" hint the user that -use-ocamlfind is required.

@vicuna
Copy link
Author

vicuna commented Sep 10, 2012

Comment author: meyer

Since the problem will go away after we implement -use-ocamlfind by default, I think the good fix for that would be to document the command line options that are not available with -no-ocamlfind, but also implement proper messages for all of them, and just halt the compilation with error if they are used with -no-ocamlfind.

@vicuna
Copy link
Author

vicuna commented Jul 29, 2013

Comment author: @gasche

Recording which command-line options and tags depend on the -use-ocamlfind option and reporting an error when they're used otherwise should be reasonably easy (marked as "junior job"). The trunk now uses -use-ocamlfind by default, but supporting -no-ocamlfind scenarios will still be useful for 4.01 (and possibly bugfixes releases).

@vicuna
Copy link
Author

vicuna commented Jul 30, 2013

Comment author: meyer

The problem should go away on trunk even when not using -use-ocamlfind, william, could you test it, and indeed see it's working?

@vicuna
Copy link
Author

vicuna commented Jul 31, 2013

Comment author: william

  • ocamlbuild -pkgs lablgtk2 -tags warn_s tree.byte
    works straight

  • ocamlbuild -no-ocamlfind -pkgs lablgtk2 -tags warn_s tree.byte
    gets the same strange warning : tag "package" does not expect a parameter, but is used with parameter "lablgtk2".
    then there is an error (as modules from lablgtk2 are not found).
    raising error explaining that "-pkgs" is not compatible with "-no-ocamlfind" would be more expressive for an end user point of view.

@vicuna
Copy link
Author

vicuna commented Aug 2, 2013

Comment author: meyer

Right, it's not so obvious how to do this, and I'd like to postpone it for the next release. I care about the quality of such patches. If you write a good patch for it I will apply it straight away. And we need proper testing of these, preferable through the ocamlbuild testsuite.

There are two things that matter here:

  • with the switches certain order is important, some of the flags just preclude other ones, but still you have a space for detecting these, and marking them redundant
  • with the tags, the predicates might not trigger the tags to be included, especially the check might happen dynamically as the dependencies come.

so proper fix, is to just use proper heuristics, and just be simple.

Patches are always warmly welcome. Thank you.

@vicuna
Copy link
Author

vicuna commented Aug 3, 2013

Comment author: @gasche

with the tags, the predicates might not trigger the tags to be included,
especially the check might happen dynamically as the dependencies come.

I think that a tag that is never triggered by any dependency of any reasonable target for the project should ultimately trigger a warning, because it may be a typo (and is useless). I mentioned this in #5212, and I think that would an important but difficult improvement to OCamlbuild's usability.

So I think it's fine if we warn on cases where the tag would actually never have been used. I would be of the opinion to have a way to mark dependencies of some tags over some configuration options (may also be useful for, say, potential menhir-specific tags), and simply refuse to work (with a proper error message) when those dependencies are not satisfied.

@vicuna
Copy link
Author

vicuna commented Aug 19, 2014

Comment author: @gasche

Fixed in 4.02@15112.

There is something subtle here, which is that the -pkg option can work without -use-ocamlfind, it only uses a different (and somewhat complex and possibly fragile that I'm glad most users don't rely on anymore) way to do things, which is to call Findlib internally instead of offloading the work to ocamlfind. So the patch disables the warning, but it does not make mandatory to pass -use-ocamlfind in these circumstances.

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

2 participants