Control of .deps folder generation location.

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Control of .deps folder generation location.

Bent Bisballe Nyeng
Hi list

I have a project in which I include a few out-of-tree cpp files in one
of my SOURCES directives.

I am currently trying to use the new subdir-objects argument but am
having the problem that autoconf tries to write a .deps folder to the
folder containing the out-of-tree files which is located in a system
folder and therefore not writable to the user.

Is it possible to somehow force autoconf to write this .deps folder in a
location inside the project tree?
Or can I perhaps resolve my issue in another way?
(I would really like avoid having to copy the out-of-tree cpp files to
an in-tree folder before compilation)

Kind regards
Bent Bisballe Nyeng

_______________________________________________
Autoconf mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/autoconf
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Control of .deps folder generation location.

Eric Blake-3
On 09/07/2016 02:42 AM, Bent Bisballe Nyeng wrote:

> Hi list
>
> I have a project in which I include a few out-of-tree cpp files in one
> of my SOURCES directives.
>
> I am currently trying to use the new subdir-objects argument but am
> having the problem that autoconf tries to write a .deps folder to the
> folder containing the out-of-tree files which is located in a system
> folder and therefore not writable to the user.
>
> Is it possible to somehow force autoconf to write this .deps folder in a
> location inside the project tree?
Creation of .deps folders is done by automake, not autoconf. You may get
a better answer from the automake lists.

However, having out-of-tree files as part of your project seems fishy;
as I understand it, automake works under the assumption that every cpp
file being compiled is part of the distribution tarball, so that the
build is reproducible (someone unpacking your tarball on their system
would otherwise have to guarantee they have the same out-of-tree cpp
files as you were building with).

> Or can I perhaps resolve my issue in another way?
> (I would really like avoid having to copy the out-of-tree cpp files to
> an in-tree folder before compilation)

But how are you making the tarball work, without those out-of-tree cpp
files?

--
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


_______________________________________________
Autoconf mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/autoconf

signature.asc (617 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Control of .deps folder generation location.

Bent Bisballe Nyeng
On 09/07/16 15:53, Eric Blake wrote:

> On 09/07/2016 02:42 AM, Bent Bisballe Nyeng wrote:
>> Hi list
>>
>> I have a project in which I include a few out-of-tree cpp files in one
>> of my SOURCES directives.
>>
>> I am currently trying to use the new subdir-objects argument but am
>> having the problem that autoconf tries to write a .deps folder to the
>> folder containing the out-of-tree files which is located in a system
>> folder and therefore not writable to the user.
>>
>> Is it possible to somehow force autoconf to write this .deps folder in a
>> location inside the project tree?
>
> Creation of .deps folders is done by automake, not autoconf. You may get
> a better answer from the automake lists.

I found out this exact thing moments after I posted to this list ;)

> However, having out-of-tree files as part of your project seems fishy;
> as I understand it, automake works under the assumption that every cpp
> file being compiled is part of the distribution tarball, so that the
> build is reproducible (someone unpacking your tarball on their system
> would otherwise have to guarantee they have the same out-of-tree cpp
> files as you were building with).
>
>> Or can I perhaps resolve my issue in another way?
>> (I would really like avoid having to copy the out-of-tree cpp files to
>> an in-tree folder before compilation)
>
> But how are you making the tarball work, without those out-of-tree cpp
> files?
>

The user is required to get those sources and then point my code to them
using a configure parameter. I know it is not nice to do it this way but
because of licensing issues with the third-party code (who allows using
their code but not distribution of it) it is the only way I can
distribute my code and still have it working.

// Bent

_______________________________________________
Autoconf mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/autoconf
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Control of .deps folder generation location.

Andrew W. Nosenko
On Wed, Sep 7, 2016 at 5:11 PM, Bent Bisballe Nyeng <[hidden email]>
wrote:

> On 09/07/16 15:53, Eric Blake wrote:
>
>> On 09/07/2016 02:42 AM, Bent Bisballe Nyeng wrote:
>>
>>> Hi list
>>>
>>> I have a project in which I include a few out-of-tree cpp files in one
>>> of my SOURCES directives.
>>>
>>> I am currently trying to use the new subdir-objects argument but am
>>> having the problem that autoconf tries to write a .deps folder to the
>>> folder containing the out-of-tree files which is located in a system
>>> folder and therefore not writable to the user.
>>>
>>> Is it possible to somehow force autoconf to write this .deps folder in a
>>> location inside the project tree?
>>>
>>
>> Creation of .deps folders is done by automake, not autoconf. You may get
>> a better answer from the automake lists.
>>
>
> I found out this exact thing moments after I posted to this list ;)
>
> However, having out-of-tree files as part of your project seems fishy;
>> as I understand it, automake works under the assumption that every cpp
>> file being compiled is part of the distribution tarball, so that the
>> build is reproducible (someone unpacking your tarball on their system
>> would otherwise have to guarantee they have the same out-of-tree cpp
>> files as you were building with).
>>
>> Or can I perhaps resolve my issue in another way?
>>> (I would really like avoid having to copy the out-of-tree cpp files to
>>> an in-tree folder before compilation)
>>>
>>
>> But how are you making the tarball work, without those out-of-tree cpp
>> files?
>>
>>
> The user is required to get those sources and then point my code to them
> using a configure parameter. I know it is not nice to do it this way but
> because of licensing issues with the third-party code (who allows using
> their code but not distribution of it) it is the only way I can distribute
> my code and still have it working.
>
>
Include these "out-of-tree" sources through #include?

--
Andrew W. Nosenko <[hidden email]>
_______________________________________________
Autoconf mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/autoconf
Loading...