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

Ocamlbuild should preserve package order if there are no dependencies #5468

Closed
vicuna opened this issue Jan 8, 2012 · 4 comments
Closed

Comments

@vicuna
Copy link

vicuna commented Jan 8, 2012

Original bug ID: 5468
Reporter: dario
Assigned to: meyer
Status: closed (set by meyer on 2012-09-16T20:44:58Z)
Resolution: fixed
Priority: normal
Severity: minor
Target version: 4.00.1+dev
Category: -for ocamlbuild use https://github.com/ocaml/ocamlbuild/issues
Monitored by: @xclerc

Bug description

Consider packages foo, bar1, and bar2, where both bar1 and bar2 depend on foo. Moreover, bar2 should appear before bar1 when linking.

The problem is if Ocamlbuild is given the _tags file below, it will correctly put foo before bar1 and bar2, but it's also likely to change the order between bar1 and bar2, causing linking problems.

true: package(bar2), package(bar1), package(foo)

This sort of problem could be easily avoided if Ocamlbuild were to preserve the package order when there is no known dependency between packages.

@vicuna
Copy link
Author

vicuna commented Feb 14, 2012

Comment author: @xavierleroy

Sounds very reasonable. Xavier C, could you please try to confirm the issue and see where it comes from in the ocamlbuild sources? Thanks!

@vicuna
Copy link
Author

vicuna commented Sep 10, 2012

Comment author: meyer

Fixed in r12909.

@vicuna
Copy link
Author

vicuna commented Sep 10, 2012

Comment author: meyer

dario could you please double check if that's what you expect, fix is on trunk.

Thanks.

@vicuna
Copy link
Author

vicuna commented Sep 11, 2012

Comment author: dario

Just checked a small dummy example with 4.01.0+dev8_2012-09-10. The order is now preserved indeed -- thanks! I still haven't been able to test it with the real world project which prompted my initial bug report though, because it depends on some external libraries which are not yet compatible with 4.00. Nevertheless, I assume it's safe to close this issue. If eventually I run into any problems I'll reopen it...

@vicuna vicuna closed this as completed Sep 16, 2012
@vicuna vicuna added this to the 4.00.1 milestone Mar 14, 2019
@vicuna vicuna added the bug label Mar 20, 2019
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