Re: Dependency cycles from C++ standard library headers

I'd vote for changing the program name.
Simpler and unless you're really stuck on having files matching c++ header
file names, no reason not to change?

-Bill

On Thu, Sep 14, 2023 at 4:02 AM Thomas Berg <[email protected]> wrote:

> 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
>

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