Conan: Use g++ default libstdcxx ABI when creating default profile

[sourcedelica]

The compiler.libcxx value set when the default profile is created should match the compiler default. For example, typically GCC >= 5 uses libstdc++11 as the default. You can find the value in:

g++ --version -v 2>&1 | grep with-default-libstdcxx-abi

If the value is with-default-libstdcxx-abi=new then use libstdc++11. This would help with Conan's out of the box behavior.

[memsharded]

While this is desirable, it might be breaking behavior for users that are currently building with libstdc++.
In CI, the default created will be libstdc++. If we now change it for libstdc++11, it will create a different package for the same environment and conditions. Should we break, @lasote?

[lasote]

In conan-package-tools should not be problems, because you explicitly generate the profiles with one or other, no default behavior. For the rest of builds, maybe yes, we should break it, I would prefer to break my build rather than generate packages with bad settings

Does it make sense to use the settings preprocessor in case it's not declared? If a user changes the gcc.version setting value and it's not set, conan could try to deduce it always. It's not so clear use case than the runtime but maybe we should think about it.

[memsharded]

I would prefer to break my build rather than generate packages with bad settings

I mostly agree, but gcc >5 with libstdc++ is not necessarily a bad setting. It is a very good setting if you plan to use that library in older distros, as you know. That is the reason it is the default, because is the most compatible setting.

[lasote]

I was thinking about the cases where we don't control well the libc++ setting, with custom or manual (without helpers) builds. But I think these could be the fewer cases. So probably you are right. In CI systems you can always use the conan profile update settings.compiler.libcxx=libstdc++11 default to set your default when you need it.

[sourcedelica]

Some more context - I'm working with an open source library that uses the default ABI. There's currently not a way to configure the library to build with a specific ABI. When I started putting a recipe together for it I ran into the issue where it Conan was tagging it with libstdc++ because of the Conan default, yet when I ran test_package it failed to link because it was actually built with libstdc++11, the GCC default.

I am going to submit a PR for that project to support explicitly setting the ABI, but I can see other people running into the same problems with other projects. That project I'm working with also does not support explicitly setting the architecture, but in that case the Conan and GCC defaults are both x86_64 so there's no problem.

Using the principle of least surprise I would expect the Conan default to match the GCC default. If you explicitly want to build with the "old" ABI for compatibility then you already know you need to do some configuration.

[lasote]

We could add a warning to the settings preprocessor to alert of the use of the old standard library instead of the ++11. But the user has to change it in the default profile, otherwise, you are going to break things.

[cleeland]

Actually, I don't think you should even capture that setting in the default profile. It's capture something that's specific to a particular compiler installation in something that can easily span multiple compilers (for example, it's not uncommon to have multiple versions of g++ as well as clang installed on the same machine). Moreover, the default profile might get magically created then the compiler upgraded and the user never knows that the old compiler's settings are enshrined in the default profile since they didn't actually create the default profile (it was a side-effect).

[memsharded]

It's capture something that's specific to a particular compiler installation

But the full default profile is capturing a particular compiler installation already.

The truth is that for production usage, using your own profiles and not the default is the way to go, specially now that they can be easily managed with conan config install. The default profile is just a convenience for getting started, tutorials, etc., and giving compiler.libcxx a default value is very useful to help in the getting started process, for newbies, etc.

[cleeland]

But the full default profile is capturing a particular compiler installation already.

Understood, but since (a) the default profile often gets created as a silent side-effect such that the user doesn't necessarily ever know it's there and (b) the default profile has a lifecycle completely unlinked to the lifecycle of "the default compiler", capturing settings dependent on The Default Compiler in the default profile sets the user up for surprises and, eventually, errors.

[cleeland]

Another common case where the current default profile behavior is inappropriate is when the home directory is shared across multiple non-homogenous machines.

[memsharded]

Yes, but also any change in installed compilers that are not properly managed in user profiles (not the default one) still leads to errors. There is no magic here, conan does not manage the user development environment, they are just a declaration of what is there. If the user changes the development environment, then it is their responsibility to update the profiles, I see no other ways.

Another common case where the current default profile behavior is inappropriate is when the home directory is shared across multiple non-homogenous machines.

I don't think this is really recommended, there are things in the conan local cache that are per-user (like remote credentials/tokens), and even if some concurrency support is provided, it is only for some certain patterns, not fully concurrent usage. Why would you share the conan cache across multiple non-homogenous machines? The conan local cache is designed for local usage.

[cleeland]

I don't think [having the home directory shared across multiple non-homogenous machines] is really recommended

Please tell that to my IT department, then. They REQUIRE that home directories exist on NFS. The fact that the cache is per-user and in the home directory is IMHO a very limiting design decision as it permits you to make assumptions about environments in which conan might get used that simply don't scale.

conan does not manage the user development environment, they are just a declaration of what is there.

I would be more inclined to agree with you if conan didn't magically create the default profile. The default profile gets created as an invisible side-effect of running conan the first time. The user doesn't have to sit down and create the profile. Consequently, the user likely has very little idea what it is, why it's there and all that it affects.

If the user changes the development environment, then it is their responsibility to update the profiles, I see no other ways.

I wish that I were as in control of my environment as you seem to believe I should be. In the corporate world, and in general, that is not necessarily the case. Projects have toolchains and operating systems dictated by external requirements; operating systems get upgraded by IT, and IT makes decisions that affect users often based on what executive management and regulatory bodies dictate. This particular issue creates quiet surprise for users when faced with those real-world situations, and that will certainly hinder adoption in my environment.

[memsharded]

I would be more inclined to agree with you if conan didn't magically create the default profile. The default profile gets created as an invisible side-effect of running conan the first time.

Yes, but conan cannot satisfy 100% to everybody, in all scenarios. If it doesn't create a default profile, then many new users, newbies, etc., will have to do some extra configuration step, and lots of people will be complaining about the steep learning curve of conan, too many things to do, why it doesn't just auto-detect my environment, it is so simple, I have just gcc installed...

In the corporate world, and in general, that is not necessarily the case. Projects have toolchains and operating systems dictated by external requirements; operating systems get upgraded by IT, and IT makes decisions that affect users often based on what executive management and regulatory bodies dictate.

We are very aware of that. In the same way IT decides which tools, etc, we see no other way that providing a configuration for all conan users, being conan config install the first step that developers should do. Not only because of profiles, but also configuring remotes (e.g. removing the default conan-center and conan-transit public remotes). This is something that corporate users have to do to keep some level of sanity. Then, getting rid of that annoying default is as simple as adding a blank default profile to the conan config install.

So conan (and any other tool, IMHO) can't do one thing and the opposite, at the same time, satisfying all needs. The default created profile is good for getting started, OSS users, etc. Corporate users definitely need conan config install not only for profiles, but for other configurations too.

[cleeland]

Okay, so with everything as it is now, how do I, as a user for whom conan created and installed default profile, know whether my profile no longer reflects the default? How do I generate different profiles for different toolchains?

The way this happens reminds me of how building a package used to be a side-effect of testing a package...which made no sense to me. You eventually separated the two activities, making building distinct from testing. I think you should do the same thing with creating profiles, and don't call it "default", call it based on what was used to determine the values in there (i.e., the toolchain, os, etc.)

If the user wants to designate a particular profile as their default, then provide a way for them to explicitly do that and explain the ramifications.

[memsharded]

If the user wants to designate a particular profile as their default, then provide a way for them to explicitly do that and explain the ramifications.

There is already a way to do this, you can configure it in your conan.conf. You can find it in the first line of http://docs.conan.io/en/latest/reference/config_files/conan.conf.html

I still understand you would like to have this as opt-in, instead of opt-out, but there are also tons of users that are quite happy with the current default. I anot opinionanted on this, if anything, I think it would make sense to run a short survey and ask conan users.

[lasote]

You could delete the contents from the default profile. No more settings guessing. Right?

[cleeland]

You could delete the contents from the default profile. No more settings guessing. Right?

Only if you know that it's there or remember that it's there. Like many things that "just work", this is easy to deal with when you remember or when it's at the forefront. The problem in the current implementation is that it's easy to never know about it or completely forget about it, and then things fail in subtle and non-obvious ways, such as what's described in #2115.

[cleeland]

564 is an old issue that deals with this same problem it seems.

[ghost]

My OSS project was delayed by at least a month because I couldn't understand why it didn't compile using Conan. Apparently, even if I have GCC 7 and it's the only compiler installed on my system, Conan still decided to use pre-5 ABI by default which is so old I completely forgot about its existence for a while. It took me maybe 2 days of full time investigation to uncover this.

[grafikrobot]

A common solution to having multiple "configurations" in the same location (the NFS shared home directory) is to distinguish those configuration files with the identity of the machine (and some time user). VisualStudio does this at the user level by storing solution settings specific to the logged in user in a sibling file to the solution. For conan it would make sense to make the default profile have a similar qualified name per machine&user IMO. This is particularly for Windows at it has transportable user home directories that can travel from one machine to the next when the same user logs into them in the same domain.