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

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

On Feb 21, 2007, at 10:37 AM, Allen Bierbaum wrote:

> Patrick Hartling wrote:
>> Doug McCorkle wrote:
>>
>>> 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?
>>>
>>
>> I don't know how to fix the bug that you are seeing. You know  
>> SCons better
>> 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.
>>
> Option 2 :)
>
> I agree with Patrick.  Let's see if we can get the bug fixed and go  
> from
> there.
>

I am happy to do that. I was looking at the issue more and it seems  
that much of the SConsAddons tools would help with some of these  
issues. Is that an option to consider or is patching what is there  
the preferred option at this point?

Doug