Re: Dependency cycles from C++ standard library headers

Thomas Berg <[email protected]> Thu, 14 Sep 2023 13:02:22 +0200
Newsgroups gmane.comp.programming.tools.scons.user
Message-ID <CABYiQpkBdQwz7xVuGFSHB6wB7H-ed4aCPw9WYyspyiY61cSfwA@mail.gmail.com>
Hi,

On Thu, 14 Sept 2023 at 12:11, Andreas Gustafsson <[email protected]> wrote:

> Hi all,
>
> When I try to build a C++ program that includes a standard library
> header of the same name as the program itself, the build fails with
> a dependency cycle.  This is on a POSIX system, where executables
> and C++ standard library headers both lack a filename extension.
>
> For example, if map.cc contains:
>
>   #include <map>
>   int main(int, char **) { }
>
> and SConstruct contains:
>
>   Program('map', ['map.cc'])
>
> scons fails with:
>
>   scons: *** Found dependency cycle(s):
>     map -> map.o -> map
>
> Same thing for programs called "random", "string", "vector", etc.
>
> Is there a way to avoid this other than renaming the program?
>

Yes you can make this work. The executable needs to be output in a
directory that isn't in the include path of the cpp file. There is a real
dependency cycle here, at least if you ignore search order for the C++
include path: the include statement could end up including the produced
binary (the way SCons sees it at least). That has to be resolved.

Not sure how you want to do that. Personally I use VariantDir in my builds,
which places build results in a different location from the source code.
And it worked for me there.

Hope this helps,
Thomas

_______________________________________________
Scons-users mailing list
[email protected]
https://pairlist4.pair.net/mailman/listinfo/scons-users