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

[Doug M. <mc...@ia...>]

On Feb 18, 2007, at 8:14 AM, Doug McCorkle wrote:

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

Anymore thoughts on these issues?

Doug