Skip to content
This repository was archived by the owner on Nov 5, 2019. It is now read-only.

Javadoc#1

Closed
lukeis wants to merge 10 commits intomasterfrom
javadoc
Closed

Javadoc#1
lukeis wants to merge 10 commits intomasterfrom
javadoc

Conversation

@lukeis
Copy link
Copy Markdown
Member

@lukeis lukeis commented Jun 30, 2016

@shs96c please review

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A short string should be a single letter :) Pydoc uses "-w", which I think is free, to mean "generate html docs". That seems appropriate.

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sounds good to me... originally tried j, but that was taken... i have no idea how someone can think '-w' implies docs, but so be it :)

@lukeis
Copy link
Copy Markdown
Member Author

lukeis commented Jul 8, 2016

merged as e620b48

@lukeis lukeis closed this Jul 8, 2016
@lukeis lukeis deleted the javadoc branch July 8, 2016 17:01
shs96c pushed a commit that referenced this pull request Nov 17, 2016
Summary:
Some object files  generated by the OCaml compiler (`.cmi`  files, for instance)
may  contain  references to  the  md5  digest of  other  object  files in  their
dependency table. This can interfere with Buck's current OCaml compilation model
in interesting ways:
  1. If the OCaml compiler references stale  output for a given target (via, say
     `.cmo`  files left  in a  build folder  after some  files were  moved to  a
     different target), the hashes expressed for the same interface in different
     OCaml binaries may not agree. This  leads to the dreaded `make inconsistent
     assumptions over interface Foo_bar` errors we all know and love.
  2. The  first problem might  be resolved by  cleaning your output  folder but,
     even if you  clean, some targets may have still  compiled correctly against
     the out-of-date build output during the previous build. Those targets would
     have  been written  to  the cache  in  a  bogus form,  leading  to new  and
     interesting errors being raised after they're  pulled from the cache on the
     next build.

Currently, the only "solution" to this problem is to clean your targets and nuke
the cache between builds. (We recently  disabled build caching for OCaml targets
to mitigate these problems.)

These changes take a  step towards improving the situation by  adding a new rule
for  OCaml targets,  `OCamlClean`.   This  rule is  added  as  a dependency  for
fine-grained `MLCompile` targets,  and ensures that the relevant  OCaml `bc` and
`opt` gen  folders are properly cleaned  for specific build targets.   This will
prevent problem  #1 from occuring and,  by extension, problem #2  as well. IIUC,
this should allow us to reenable caching for OCaml build rules.

Test Plan: CI

Reviewed By: k21

fbshipit-source-id: 3712224
shs96c pushed a commit that referenced this pull request Sep 7, 2017
Summary:
When Xcode compiles static Swift libs, it will include linker commands (`LC_LINKER_OPTION`) that will be carried over for the final binary to link to the appropriate Swift overlays and libs. This means that the final binary must be able to locate the Swift libs in the library search path. If an Xcode target includes Swift, Xcode will automatically append the Swift lib folder when invoking the linker. For example, it will insert the following path:

    /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/macosx

which can be dynamically specified as:

    $DT_TOOLCHAIN_DIR/usr/lib/swift/$PLATFORM_NAME

Unfortunately, this will not happen if we have a plain `apple_binary` that has Swift deps. So we're manually doing exactly what Xcode does to make sure binaries link successfully if they use Swift directly or transitively.

To extract `LC_LINKER_OPTION` from a static library:

    otool -l libFoo.a

You will be able to see output like:

    Load command 17
         cmd LC_LINKER_OPTION
     cmdsize 32
       count 1
      string #1 -lswiftCoreGraphics

Test Plan: Automated tests part of diff + manual Buck setup test

Reviewed By: VTopoliuk

fbshipit-source-id: f76171b
shs96c pushed a commit that referenced this pull request Aug 24, 2018
Reviewed By: styurin

fbshipit-source-id: 8fcae2dd97
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants