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

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

> Allen Bierbaum wrote:
>> Patrick Hartling wrote:
>>> Doug McCorkle wrote:
>>>
>>>> Hello,
>>>>      Currently, when building cppdom, headers and libs are installed
>>>> in prefix even if the install target is not listed. This causes
>>>> issues when trying to make cppdom accessible through MacPorts. In
>>>> general this seems to be somewhat of a problem.
>>>>
>> Doug:
>>
>> I am coming to this a little late, but what is the problem building
>> inside MacPorts?  Is there a requirement that build happens separately
>> from install?
>
> All packaging utilities that I know of separate building from installin=
g.
> Watching MacPorts builds run, they definitely do this, though I don't k=
now
> if it is a strict requirement. I bet that it is, though.
>

This is a strict requirement of MacPorts because it defaults to autoconf
tools and stages the build before intsalling therefore when files appear
in the true installation dir /opt/local that it did not put there MacPort=
s
complains.
>> cppdom is definitely not designed to do that.  It has been designed to
>> follow a fairly common best practice of having one command that does a
>> complete build and install and does it every time (it is also
>> recommended to have this run the testsuite, but we don't have that in
>> there yet. :).
>
> Where is this stated as being a best practice? I would think that nearl=
y
> every library in existence allows for separate build and install steps.
> Those that don't are going to make packaging a pain. For example, when =
you
> build an RPM to be installed in /usr, you don't actually want it to go
> into
> /usr during the packaging process. It has to go into a staging area (wh=
ich
> is something that MacPorts uses) wherein the actual package is created.
> So,
> there end up being two installation trees: the staging area using durin=
g
> packaging and the final destination when the package is installed. If y=
ou
> look at the RPM spec file for CppDOM, you'll see a hack where cppdom.fp=
c
> 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 ther=
e
>> 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 f=
rom
> building it. Having a developer installation is one thing, but that
> shouldn't interfere with users being able to build and install the
> software.
>
>> 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
>>
I understand the points above but I can not make it work correctly with o=
r
without prefix being specified.

>> 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.fp=
c
> gets generated as part of the build. If the prefix changes, it doesn't =
get
> regenerated (which seems like a bug). This is something that I know I h=
ave
> seen, and this exact usage is what I was alluding to earlier when I sai=
d
> "running the build separately from the installation doesn't work well."
>
I see the same thing you do Patrick. These files do not seem to be
regnerated properly.

[snip]

Doug