Hi
Sorry for late request for 14.1.

As it turned out, I going to use Boost library intensively, and planning to do it on brand new S 14.1 version. I going to use gnu toolchain to detect and check proper version of library. But unfortunately Boost itself does not provides any helper library for it(I mean special .m4 macros) and usage of generic one is a bit boring(and pretty hard for me taking into account my beginner status in this field).

So I googled and found recommendations to use 3rd-party one from here. Copied it /usr/share/aclocal and tested a little in 13.37 environment and in -current also(i486). Seems to work fine for me.

So I humbly asking Pat to include this little magical file to -current(as a part of Boost package I think) and it would be great if it will be included into upcoming 14.1.

Well, I know I can manually put into proper path, even create separate package for it, but I think it will be better if it will be distributed aggregated into main Boost packages.

Thank you

Did you ask upstream (the maintainers of the boost library) so they include the file into their source package?

Slackware usually comes with vanilla software.

1 members found this post helpful.

No I didn't yet(as posting this answer, already did) but I don't think I first user who has such request. I think, even if Pat decides to fulfil my request for next release(after 14.1) it will be faster than Boost maintainers will react on my request in mailing-list.

> Slackware usually comes with vanilla software.
Wrong. Slackware usually comes with stable software. For some packages stable==vanilla, for others stable==vanilla+upstream|3rd-party patches(see kernel packages from one of former releases). Even this last case I consider to call vanilla, because that patches are no secret self-made by PV and Co workarounds.

Slackware will patch things to fix bugs if necessary, but generally will not add patches for the purpose of introducing new features. In this case I see the request as being more of a feature request than a bug report.

3 members found this post helpful.

That's exactly the thinking behind distributions with non-vanilla packages. It leads to weird forks, serious security problems and upstream programmers upset with distro package maintainers, because they have to deal with bugs they didn't introduce.

A boost.m4 created by a third party may be great for your use-case, but will eventually break builds of other people. I can't judge that, because I don't know much about the whole GNU autohell system (and don't want to). But I'm sure the boost maintainers know the implications and may intentionally have decided to not support it. Boost itself is build with their own tool "Boost.Jam" for a reason.

1 members found this post helpful.

I stick with vanilla Build. The truth is there is some very hacked header files that have been produced to build custom projects and this tends to leave me using custom boost on certain systems that have been setup to compile these programs.
Such as boost coroutine did not go into the stock build till 1.5.3. But many projects have been based around it added to the 1.4.8 to the 1.5.2 and this has caused well good and bad things.

It really makes the vanilla boost useless because on the custom projects. The main development of boost has gone one direction while the custom I call it add on has tried to change it to fit there programs. Good or bad two different Horses.

This tends to keep a certain distro from going vanilla and it is not good or bad just different.

but the required m4 macro into your project and configure you project to use it, this is the common way to handle such situations
this may helps:
http://www.gnu.org/software/automake...al-Macros.html

@a4z, this solution for 1,2,... 5 projects. But not for 20+ projects and for students like me who tend to do the same errors repeatedly.

Ok. Let forget temporary my original request(to include .m4 into boost package), and discuss alternatives.
Alternative 1:
Actually I did it already locally, and it not worth to mention here, I think but for sake for clarity I shall: To create separate package which contains mentioned file. I think it does not conflict with quoted declaration.

Alternative 2:
In boost-user mailing-list I was advised to try to use macros from Autoconf Archive. I did not found any ax_ files neither in my 13.37 installation, nor in MANIFEST.bz2 in -current. On SBo there is no mention of it also. So request: to introduce new package(autoconf-archive) which includes those extra macroses which useful not only for boost detection but for some other software also.