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

[Allen B. <al...@vr...>]

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.

-Allen