Re: [xml-cppdom-devel] Building cppdom prefix problem

[Patrick H. <pa...@13...>]

Doug McCorkle wrote:
> On Feb 18, 2007, at 8:14 AM, Doug McCorkle wrote:
>=20
>>>
>> [snip]
>>
>>>>> If you
>>>>> look at the RPM spec file for CppDOM, you'll see a hack where
>>>>> cppdom.fpc
>>>>> gets edited after running 'scons install' to change the staging
>>>>> area prefix
>>>>> to the final destination prefix.
>>>>>
>>>>>
>>>>>> That way developers are *always* using the same build
>>>>>> paths that are used by users and packages to install the tool
>>>>>> and there
>>>>>> are no special hoops to jump through to install or package the
>>>>>> software.
>>>>>>
>>>>> Not everyone is a developer. Installing a package is a separate
>>>>> thing from
>>>>> building it. Having a developer installation is one thing, but that=

>>>>> shouldn't interfere with users being able to build and install
>>>>> the software.
>>>>>
>>>>>
>>>> Exactly, and that is the point.  The idea is to keep from getting
>>>> bitten
>>>> by the "developer using a separate build process" problems that have=

>>>> plagued us in the past.  The build the developer uses as part of
>>>> their
>>>> everyday process is exactly the same as what someone uses for
>>>> installation.  (ok, I fibbed a bit here, in the case of developer on=

>>>> linux we replace the copy command with a link command, but all the
>>>> code
>>>> being run is the same)
>>> I am not saying that developers should use a build process that is
>>> disjoint
>>> from what users do. I think that developers should use a superset
>>> of the
>>> build process that users need. Users need build+install. If
>>> installation
>>> does the build first by default (seems like a handy thing for it to
>>> do),
>>> then they can skip a step. However, if building does installation
>>> whether
>>> the user wants it or not, then that is a problem. The two seem to be
>>> intermingled in this case, and that is causing Doug's problem.
>>>
>>>>>> Just one magic button that will take you from source to
>>>>>> happiness. I hadn't heard of this causing problems before, so I am=

>>>>>> interested in hearing more here.
>>>>>>
>>>>>> If you really need the build and install separated, you could do
>>>>>> something like this:
>>>>>>
>>>>>> - Build
>>>>>>    - call scons without a prefix setting
>>>>>> - Install
>>>>>>    - call scons with a prefix setting
>>>>>>
>>>>>> This will end up "installing" cppdom in the development
>>>>>> directories on
>>>>>> the first call, but it should work for you.
>>>>>>
>>>>> I am just about positive that that process won't work because
>>>>> cppdom.fpc
>>>>> gets generated as part of the build. If the prefix changes, it
>>>>> doesn't get
>>>>> regenerated (which seems like a bug).
>>>> That is definitely a bug.  It should be regenerated.  Running the
>>>> build
>>>> at any point should generate all files again that need to be
>>>> changed for
>>>> the new installation path.  That is the whole point of the single
>>>> build
>>>> process. :)
>>>>
>>>> I don't have time to look at this today, but I will do what I can to=

>>>> help out.
>>> Wasn't there a change made to the CppDOM build to work around a bug
>>> in SCons
>>> where it would scan the entire installation prefix? The result
>>> would be that
>>> installation would hang if the installation prefix was the root of a
>>> directory tree of even moderate size. I can't find the revision
>>> where that
>>> happened, so maybe I an thinking of a different project. Being an
>>> SCons
>>> novice at best, it seems to me that the bug is that the
>>> installation prefix
>>> is not seen by SCons as being a dependency of cppdom.fpc, and this
>>> is what
>>> causes the problem. If that is the problem, is there a simple fix?
>>>
>> [snip]
>>
>> I understand that there may be some differences in thought in how
>> builds should work but what is the solution to the problems at hand?
>> I am somewhat confused on what would need to be done to address some
>> of the issues that were discussed in this thread.
>>
>=20
> Anymore thoughts on these issues?

I don't know how to fix the bug that you are seeing. You know SCons bette=
r
than I do. If you have a fix, submit it, and I will check it in. Allen's
silence is usually an indication that he has lost interest or has no time=
 to
pursue the matter further.

 -Patrick


--=20
Patrick L. Hartling                    | VP Engineering, Infiscape Corp.
PGP: http://tinyurl.com/2oum9          | http://www.infiscape.com/