1. 06 Sep, 2016 1 commit
  2. 12 Jul, 2016 1 commit
  3. 20 Jun, 2016 1 commit
  4. 30 Mar, 2016 1 commit
  5. 15 Mar, 2016 1 commit
  6. 20 Jan, 2016 1 commit
  7. 18 Dec, 2015 1 commit
  8. 02 Sep, 2015 1 commit
  9. 24 Aug, 2015 1 commit
  10. 19 May, 2015 1 commit
  11. 24 Apr, 2015 1 commit
  12. 13 Apr, 2015 1 commit
  13. 31 Mar, 2015 2 commits
  14. 26 Mar, 2015 1 commit
  15. 25 Mar, 2015 1 commit
  16. 19 Mar, 2015 1 commit
  17. 05 Feb, 2015 1 commit
  18. 25 Jan, 2015 1 commit
  19. 21 Jan, 2015 1 commit
  20. 20 Jan, 2015 1 commit
  21. 19 Jan, 2015 1 commit
  22. 17 Jan, 2015 1 commit
  23. 16 Jan, 2015 1 commit
  24. 13 Jan, 2015 2 commits
  25. 12 Jan, 2015 1 commit
  26. 11 Jan, 2015 1 commit
  27. 08 Dec, 2014 1 commit
  28. 06 Dec, 2014 1 commit
  29. 24 Nov, 2014 1 commit
  30. 23 Oct, 2014 2 commits
  31. 22 Oct, 2014 1 commit
  32. 03 Sep, 2014 3 commits
  33. 27 Aug, 2014 1 commit
  34. 22 Aug, 2014 1 commit
  35. 26 Jun, 2014 1 commit
    • Martin Storsjö's avatar
      Include private dependencies automatically in pkg-config for non-shared builds · c8b1d2fa
      Martin Storsjö authored and Niels Möller's avatar Niels Möller committed
      When a user invokes pkg-config to get the necessary linker flags
      for linking to libhogweed, the user can add --static to get the
      private dependencies included, which are necessary for static
      linking. If the hogweed build contains both static and shared
      libraries, this works as intended - if the user explicitly passes
      -static to the linker to have it favor static libs over shared
      ones, the same user also needs to tell pkg-config about this intention.
      
      If the hogweed build happens to be static-only, the user of the
      library might not be aware of this, and might not realize needing
      to pass --static to pkg-config. (This is even more an issue in
      setups with a large number of libraries, where only a few of them
      are built static-only.)
      
      For these cases, where a library is built as only a static library,
      one fairly common convention (not used everywhere, but at least in
      some libraries I regularly use) is to include the private dependencies
      in the non-private section. This makes sure a user of the library
      doesn't need to be concerned about which way this library was built
      (unless the user intentionally overrides defaults by passing
      flags such as -static to the linker).
      c8b1d2fa