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

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

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

Doug