On Mon, 18 Jun 2018 16:52:01 -0600 Mathieu Poirier mathieu.poirier@linaro.org wrote:
On Mon, 18 Jun 2018 at 16:29, Kim Phillips kim.phillips@arm.com wrote:
On Mon, 18 Jun 2018 15:51:34 -0600 Mathieu Poirier mathieu.poirier@linaro.org wrote:
On Mon, 18 Jun 2018 at 15:25, Kim Phillips kim.phillips@arm.com wrote:
On Fri, 15 Jun 2018 16:22:33 -0600 Mathieu Poirier mathieu.poirier@linaro.org wrote:
On Fri, 15 Jun 2018 at 15:54, Kim Phillips kim.phillips@arm.com wrote:
The code ought to be able to handle, and remain backwards compatible with an older version of the library.
Once again I do not agree. It is only normal that developers take advantage of new functionality available in a library and it happens all the time.
Not when it breaks the build for the older version of the library. Where do you see that happening with the upstream perf tool?
Any library embedded in the perf tools (as openCSD is) works exactly
The openCSD library is not embedded in the perf tool source tree. libopencsd is a standalone library: it's available by itself, and tools like perf can optionally detect and use it.
the same way. If people are doing development work they are expected to work with the latest revision of the library they are using. For
Not necessarily: Hello world doesn't require the latest C library.
Try using the latest features of the C library on any old system, things will break.
which is why we have tools like autoconf to handle working around any missing features.
distributions the linux tools package picks up the latest revision.
libopencsd will only be updated upon distribution maintainer and user update action. Meanwhile, perf should continue to build no matter what.
Distribution perf tools and the openCSD library are always in sync, that's not a problem.
Not on my system. I don't know how you can say that that will be guaranteed going forward, either.
When downloading the latest revision of the perf tools, it is normal that the latest features may not be present in the libraries available on the system - this is true for any library. OpenCSD provides flags to compile with an alternate (i.e newer) revision of the library exactly for those situations. Those are well documented and I've used them many times.
Right but any version of perf should be able to build against any version of libopencsd. If a feature isn't present, it should fall back to its old behaviour.
I think Rob was looking at a way to warn users about an openCSD that is too old.
That's fine, but perf should still build without crippling users with older versions of libraries installed.
And how do we do this? We add #ifdefs everywhere? Every tool I've
That would work.
That is impossible to maintain, which is why people simply don't do that.
There are ifdefs in the perf tool source, granted not a lot, but this is what we have to do if libopencsd is going to add features in an incompatible manner.
recompiled needs a specific version of a library... This standard practice.
Not in the upstream perf tool.
Then we agree to disagree.
I've looked, and haven't been able to find an instance of code in the perf tool source that fails to build given a newer version of a library is not available. Where does it do this?
Can the dependent libopencsd change be possibly reverted, and re-done in a backward-compatible manner?
Thanks,
Kim