Thread: [xml-cppdom-devel] SConstruct patch

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Hello,

      Attached is a patch that changes the SConstruct to encode the  
relative flagpoll variable in the fpc file rather than utilize the  
absolute path for prefix.

Doug

Doug McCorkle wrote:
> Hello,
>=20
>      Attached is a patch that changes the SConstruct to encode the
> relative flagpoll variable in the fpc file rather than utilize the
> absolute path for prefix.

With this patch, headers end up getting installed into /include/cppdom-0.=
7.8
instead of <prefix>/include/cppdom-0.7.8. I think that
base_inst_paths['include'] plays a more important role than just influenc=
ing
what ends up in the generated .fpc file.

 -Patrick

--=20
Patrick L. Hartling
VP Engineering, Infiscape Corp.
http://www.infiscape.com/

On Jun 28, 2007, at 8:36 AM, Patrick Hartling wrote:

> Doug McCorkle wrote:
>> Hello,
>>
>>      Attached is a patch that changes the SConstruct to encode the
>> relative flagpoll variable in the fpc file rather than utilize the
>> absolute path for prefix.
>
> With this patch, headers end up getting installed into /include/ 
> cppdom-0.7.8
> instead of <prefix>/include/cppdom-0.7.8. I think that
> base_inst_paths['include'] plays a more important role than just  
> influencing
> what ends up in the generated .fpc file.

Thanks for catching the mistake. Attached is a revised patch. I also  
cleaned up some other aspects of the previous patch.

Doug

On Jun 28, 2007, at 9:06 AM, Doug McCorkle wrote:

>
> On Jun 28, 2007, at 8:36 AM, Patrick Hartling wrote:
>
>> Doug McCorkle wrote:
>>> Hello,
>>>
>>>      Attached is a patch that changes the SConstruct to encode the
>>> relative flagpoll variable in the fpc file rather than utilize the
>>> absolute path for prefix.
>>
>> With this patch, headers end up getting installed into /include/ 
>> cppdom-0.7.8
>> instead of <prefix>/include/cppdom-0.7.8. I think that
>> base_inst_paths['include'] plays a more important role than just  
>> influencing
>> what ends up in the generated .fpc file.
>
> Thanks for catching the mistake. Attached is a revised patch. I  
> also cleaned up some other aspects of the previous patch.
>

I was just wondering if this patch is ok or if there are also  
problems with this implementation?

Doug

Doug McCorkle wrote:
> On Jun 28, 2007, at 9:06 AM, Doug McCorkle wrote:
>=20
>> On Jun 28, 2007, at 8:36 AM, Patrick Hartling wrote:
>>
>>> Doug McCorkle wrote:
>>>> Hello,
>>>>
>>>>      Attached is a patch that changes the SConstruct to encode the
>>>> relative flagpoll variable in the fpc file rather than utilize the
>>>> absolute path for prefix.
>>> With this patch, headers end up getting installed into /include/=20
>>> cppdom-0.7.8
>>> instead of <prefix>/include/cppdom-0.7.8. I think that
>>> base_inst_paths['include'] plays a more important role than just =20
>>> influencing
>>> what ends up in the generated .fpc file.
>> Thanks for catching the mistake. Attached is a revised patch. I =20
>> also cleaned up some other aspects of the previous patch.
>>
>=20
> I was just wondering if this patch is ok or if there are also =20
> problems with this implementation?

It was fine. I committed it a week ago.

 -Patrick

--=20
Patrick L. Hartling
VP Engineering, Infiscape Corp.
http://www.infiscape.com/

On Jul 5, 2007, at 9:17 AM, Patrick Hartling wrote:

> Doug McCorkle wrote:
>> On Jun 28, 2007, at 9:06 AM, Doug McCorkle wrote:
>>
>>> On Jun 28, 2007, at 8:36 AM, Patrick Hartling wrote:
>>>
>>>> Doug McCorkle wrote:
>>>>> Hello,
>>>>>
>>>>>      Attached is a patch that changes the SConstruct to encode the
>>>>> relative flagpoll variable in the fpc file rather than utilize the
>>>>> absolute path for prefix.
>>>> With this patch, headers end up getting installed into /include/
>>>> cppdom-0.7.8
>>>> instead of <prefix>/include/cppdom-0.7.8. I think that
>>>> base_inst_paths['include'] plays a more important role than just
>>>> influencing
>>>> what ends up in the generated .fpc file.
>>> Thanks for catching the mistake. Attached is a revised patch. I
>>> also cleaned up some other aspects of the previous patch.
>>>
>>
>> I was just wondering if this patch is ok or if there are also
>> problems with this implementation?
>
> It was fine. I committed it a week ago.
>

OK. The sourceforge veiwsvn must be slow in getting those changes on  
the public page. Thanks!

Doug