[question] Please document `settings_target` and its difference from `settings`

[DoDoENT]

What is your question?

I'm curious about the difference between self.settings and self.settings_target. I understand that self.settings_build refer to settings on the build machine, and that self.settings refer to host (target) for which package is built. However, why is then self.settings_target needed?

I've search the documentation for settings_target keyword, and found almost nothing. There is only a obscure mention in "Adding information" part of the package_id method documentation , a brief mention in XCRun documentation, without any explanation, and a broken link in "Read more" section of "Tool requires packages".

I've basically discovered the settings_target by reading these weird comments in the official Android NDK conan package.

While creating my own NDK conan package, I wanted to make a similar validation, so I initially wrote the validate method in my recipe like this:

def validate(self):
    if self.settings.os != "Android":
        raise ConanInvalidConfiguration(
            f"You've added {self.ref} as a build requirement, while os={self.settings.os} != Android"
        )
    if self.settings.compiler != 'clang':
        raise ConanInvalidConfiguration(
            f"Android NDK only supports clang compiler, while compiler={self.settings.compiler} != 'clang'"
        )
    if self.settings.compiler.libcxx not in ['c++_static', 'c++_shared', 'libc++v2']:
        raise ConanInvalidConfiguration(f'Unsupported libcxx library:{self.settings.compiler.libcxx}')

However, this validation always failed, both when creating the package (which is kind of expected, since I was creating the package using profile for my mac), and while using the package (which I didn't expect, since host system was now Android, and build system was mac, so WTF?!?).

Then, I rewrote my validate like this:

def validate(self):
    if self.settings_target.os != "Android":
        raise ConanInvalidConfiguration(
            f"You've added {self.ref} as a build requirement, while os={self.settings_target.os} != Android"
        )
    if self.settings_target.compiler != 'clang':
        raise ConanInvalidConfiguration(
            f"Android NDK only supports clang compiler, while compiler={self.settings_target.compiler} != 'clang'"
        )
    if self.settings_target.compiler.libcxx not in ['c++_static', 'c++_shared', 'libc++v2']:
        raise ConanInvalidConfiguration(f'Unsupported libcxx library:{self.settings_target.compiler.libcxx}')

... and this failed with accessing None object, because apparently sometimes self.settings_target is None. Why? I've seen this being raised as an issue where another toolchain is being packaged into conan.

My final version of validate is this:

def validate(self):
    if self.settings_target is not None:
        if self.settings_target.os != "Android":
            raise ConanInvalidConfiguration(
                f"You've added {self.ref} as a build requirement, while os={self.settings_target.os} != Android"
            )
        if self.settings_target.compiler != 'clang':
            raise ConanInvalidConfiguration(
                f"Android NDK only supports clang compiler, while compiler={self.settings_target.compiler} != 'clang'"
            )
        if self.settings_target.compiler.libcxx not in ['c++_static', 'c++_shared', 'libc++v2']:
            raise ConanInvalidConfiguration(f'Unsupported libcxx library:{self.settings_target.compiler.libcxx}')

... which works correctly, but I don't understand why.

Have you read the CONTRIBUTING guide?

• I've read the CONTRIBUTING guide

[memsharded]

Hi @DoDoENT

Thanks for your question.

Some quick feedback:

by reading these weird comments in the official Android NDK conan package.

Some package being in ConanCenter does not make it "official". It doesn't mean that users should be using this package for Android builds, it is perfectly valid to use a normal AndroidNDK installed in the system. You surely know, but I thought it was worth clarifying for other users.

It is likely that the piece you are missing while building your NDK package is:

conan create . --build-require -p:b=buildprofile -p:h=hostprofile

This will create the package as a tool_require, and assuming hostprofile is Android, and lets say buildprofile is Linux:

• settings == settings_build == Linux
• settings_target == Android

[memsharded]

In any case, yes, I agree this needs better documentation, and some good examples too.

[DoDoENT]

It is likely that the piece you are missing while building your NDK package is:

OK, I missed the --build-require - by adding this parameter, conan test passes correctly (uses Android, instead of Mac).

However, my validate still needs to use settings_target. It's not clear to me why settings == settings_build in this case. I was under impression that settings is always in "host" context, and settings_build in "build" context (if it's different).

Even the settings_build is only briefly mentioned in documentation about generate.

I think it would be a good value to add both settings_target and settings_build to the list of attributes in the documentation. Currently, only settings is fully documented.

Also, how come you've decided to call the host settings settings_target, instead of settings_host, since you are using GNU's terminology everywhere else (meaning "host" is the target system, and "build" is the "host system where you build the package")?

Even though I personally prefer the non-GNU terminology (target and host), I think that at least Conan should be consistent with itself, meaning that either settings_target should be renamed to settings_host or everything else should start using target/host. I think the former is easier to make, without breaking the world (simply mark settings_target as "deprecated" in favor of settings_host).

Also, are there any more hidden features, like, e.g. options_build/options_target to be usable from configure to configure a dependency only in the build context (e.g. if the same dependency is both in the build and host context)? I will have a use-case for that, and documentation just shows options_build as command-line flag.

[memsharded]

Also, how come you've decided to call the host settings settings_target, instead of settings_host, since you are using GNU's terminology everywhere else (meaning "host" is the target system, and "build" is the "host system where you build the package")?

Let me try to clarify it. In our example:

• Build: The machine it is currently building in. Our Windows machine. settings_build.os == Windows
• Host: The machine that will run the package. This will run in Windows too, the android-ndk will not run in Android itself. settings.os == Windows
• Target: The machine where the output of the execution of the current package will run. settings_target.os==Android

[DoDoENT]

Thank you for the clarification. It makes sense now.

In the future, it would be nice to have this same clarification in the official documentation as well.