One observation that i made over the past decades that most non-trivial chunks of C++ software brought their own build system or at least force users to use the given one or suffer.

 When there was unix and make, manually editing makefiles was considered an art, but doable. However, multiple styles of where to put stuff in directories, etc emerged. X11 brought makedepend that at least could rid the tedious header dependency aspect. But on non Unix (microsoft and others) tooling had enough differences that cross platform was almost impossible, or meant porting or providing a dedicated build system, or have platform specific tooling for your stuff.

If there would be a one-size-fits-all solution, we would have that already. And the platform ownership strategy worked against that.

The biggest problem is that different solutions usually do not merge easily. So to combine library A with library B that use different build tools requires manual labor, or even the use of a third tool. Resulting in even more proliferation or hackish solutions solving the individual project-specific problems without generalization.

I think to provide good basis is to collect the problems that are solved by the different current mismatched tools and then try to find out what part can be standardized to remedy the situation. But hopes are low...


Sent from Peter Sommerlad's iPad
+41 79 432 23 32

> On 5 Apr 2018, at 19:34, Titus Winters <titus_at_[hidden]> wrote:
>
> Can you provide concrete examples of the problems you've encountered? Can these be tooled around? (For instance, we build a database of all symbols potentially known to the pre-processor for a given project and see where the potential incompatibilities lie?)
>
>> On Thu, Apr 5, 2018 at 1:29 PM Rene Rivera <grafikrobot_at_[hidden]> wrote:
>>> On Thu, Apr 5, 2018 at 12:14 PM, Titus Winters <titus_at_[hidden]> wrote:
>>> There's been some general pushback on "macros and preprocessor things make various types of tools impossible to deploy." My question is aimed mostly at that: do we have evidence of that? Or is it just intuition?
>>
>> Ah, yes.. In that respect macros make build systems life very difficult. As it totally kills any hope of determining binary compatibility. Boost Build totally ignores them in that respect. And it becomes a problem for the user to deal with. Which in turn propagates to package managers as consumers of the build system products.
>>
>> --
>> -- Rene Rivera
>> -- Grafik - Don't Assume Anything
>> -- Robot Dreams - http://robot-dreams.net
>>
>> _______________________________________________
>> Tooling mailing list
>> Tooling_at_[hidden]
>> http://www.open-std.org/mailman/listinfo/tooling
> _______________________________________________
> Tooling mailing list
> Tooling_at_[hidden]
> http://www.open-std.org/mailman/listinfo/tooling