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

[Patrick H. <pa...@13...>]

Allen Bierbaum wrote:
> Patrick Hartling wrote:
>> Doug McCorkle wrote:
>>  =20
>>> Hello,
>>>      Currently, when building cppdom, headers and libs are installed =
=20
>>> in prefix even if the install target is not listed. This causes =20
>>> issues when trying to make cppdom accessible through MacPorts. In =20
>>> general this seems to be somewhat of a problem.
>>>    =20
> Doug:
>=20
> I am coming to this a little late, but what is the problem building=20
> inside MacPorts?  Is there a requirement that build happens separately =

> from install?

All packaging utilities that I know of separate building from installing.=

Watching MacPorts builds run, they definitely do this, though I don't kno=
w
if it is a strict requirement. I bet that it is, though.

> 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=20
> recommended to have this run the testsuite, but we don't have that in=20
> there yet. :).

Where is this stated as being a best practice? I would think that nearly
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 yo=
u
build an RPM to be installed in /usr, you don't actually want it to go in=
to
/usr during the packaging process. It has to go into a staging area (whic=
h
is something that MacPorts uses) wherein the actual package is created. S=
o,
there end up being two installation trees: the staging area using during
packaging and the final destination when the package is installed. 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 pref=
ix
to the final destination prefix.

> That way developers are *always* using the same build=20
> paths that are used by users and packages to install the tool and there=
=20
> are no special hoops to jump through to install or package the=20
> software.

Not everyone is a developer. Installing a package is a separate thing fro=
m
building it. Having a developer installation is one thing, but that
shouldn't interfere with users being able to build and install the softwa=
re.

> Just one magic button that will take you from source to=20
> happiness. I hadn't heard of this causing problems before, so I am=20
> interested in hearing more here.
>=20
> If you really need the build and install separated, you could do=20
> something like this:
>=20
> - Build
>    - call scons without a prefix setting
> - Install
>    - call scons with a prefix setting
>=20
> 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 ge=
t
regenerated (which seems like a bug). This is something that I know I hav=
e
seen, and this exact usage is what I was alluding to earlier when I said
"running the build separately from the installation doesn't work well."

 -Patrick

>> That sounds like bad behavior in general. Software shouldn't be instal=
ling
>> itself unless told to do so.
>>
>> The CppDOM build is in pretty bad shape and hasn't ever been quite wha=
t I
>> would call ideal. The installation part has never really worked correc=
tly,
>> but I don't think I have seen this specific behavior. What I have seen=
 is
>> that running the build separately from the installation doesn't work w=
ell,
>> but the build certainly should support a two-step build+install proces=
s.
>> What version are you using?
>>
>>  =20
>>> I "fixed" the problem =20
>>> by adding guards in the scons files but that may not be the solution =
=20
>>> everyone is looking for. Thoughts?
>>>    =20
>> What are guards in this context?
>>
>>  -Patrick

--=20
Patrick L. Hartling                    | VP Engineering, Infiscape Corp.
PGP: http://tinyurl.com/2oum9          | http://www.infiscape.com/