Buck: platform_linker_flags not working correctly?

Created on 12 Apr 2017 · 16Comments · Source: facebook/buck

I'm trying to customize my build using platform specific libraries.
Unfortunately i can't get it working on debian nor osx.
For some reason platform_linker_flags are only matching on default.

#BUCK 
cxx_binary(
  name = 'foo',
  header_namespace = 'foo',
  srcs = glob([
    'src/**/*.cpp',
  ]),
  headers = subdir_glob([
    ('include', '**/*.hpp'),
  ]),
  platform_linker_flags = [
    ('^linux.*', ['-lbar'])
  ],
)

buck version: adc0f78a68db45334098ac083171c7c2ebc32a8c (v2017.03.29)
uname -s returns Linux
in java: System.getProperty("os.name") returns 'Linux' as well.

Source

nikhedonia

All 16 comments

Can confirm the same issue on macOS - the platform is "default"

njlr on 12 Apr 2017

Confirmed - Ditto for us. Let me know if you need an example project created.

voznesenskym on 12 Apr 2017

What is the command you are running? This might only work if you explicitly run buck build target#linux-x86_64.

Coneko on 18 Apr 2017

👍1

I get the error when running just buck build :my-target. Do we have to specify the target for every build? Seems like it would be more streamlined if the platform macro expanded to the actual host platform by default.

njlr on 18 Apr 2017

I don't know, depends on whether it works if you expand it manually. If it doesn't it could be another issue.

Coneko on 18 Apr 2017

I have made a small C++ project here: https://github.com/njlr/buck-platforms.

Here are my results on macOS:

  buck run :hello
  Hello from default

  buck run :hello#macosx-x86_64
  Hello from macOS

  buck run :hello#linux-x86_64
  Unrecognized flavor in target //:hello#linux-x86_64 while parsing //BUCK

njlr on 18 Apr 2017

I can confirm. On Linux i have the same behavior but the other way around:

  buck run :hello
  Hello from default

  buck run :hello#linux-x86_64
  Hello from linux

  buck run :hello#macosx-x86_64
  Unrecognized flavor in target //:hello#macosx-x86_64 while parsing //BUCK

nikhedonia on 19 Apr 2017

Yep, then it's what I mentioned above.

cc @andrewjcg, @Ktwu was either of you two looking at this?

Coneko on 19 Apr 2017

👍1

cc @mzlee as well.

Coneko on 19 Apr 2017

Any updates? - as more people and buckaroo packages depend on flavors, this is becoming a bigger annoyance day by day...

nikhedonia on 22 Aug 2017

👍1

The reason for current behavior is that platform is matched against a flavor and by default that flavor is default. I don't know a context behind this, so I can't say if it's intentional or not. If nobody picks this task up, I'll try take a look hopefully later this week.

ttsugriy on 22 Aug 2017

🎉1

In fact there is even a comment about this behavior:

// Finalize our "default" host.
// TODO(kelliem) The host flavor should default to a concrete flavor
// like "linux-x86_64", not "default".

ttsugriy on 22 Aug 2017

is anybody currently working on this ?

nikhedonia on 30 Aug 2017

Yeah, Buck doesn't setup host-specific build platforms (it's basically just "default" for the host platform, and Android and iOS specific platforms for everything else), which makes this kind of thing a pain.

Some possible short-term ways forward, depending on what your trying to do:
1) If you don't really care about cross-compilation, you can probably get using some logic in the BUCK file itself to detect the OS type (e.g. with import platform; platform.system()) and add flags to plain old linker_flags instead.
2) Setup you're own linux and platform in .buckconfig. Since Buck doesn't yet support configuring a host-dependent cxx.default_platform value, this would unfortunately require an explicit flavor being set for each build.