Menu
▾
▴
Re: [xml-cppdom-devel] Building cppdom prefix problem
|
From: Allen B. <al...@vr...> - 2007-02-16 17:19:35
|
Patrick Hartling wrote: > 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 installing. > Watching MacPorts builds run, they definitely do this, though I don't know > 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 >> 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? Many software engineering techniques have concepts similar to this one. They all revolve around continuous integration (http://en.wikipedia.org/wiki/Continuous_integration). The main point being that a full build is always happening and that the user can get from code to fully complete build in one step with nothing to manual processes in between. This is exactly the type of thing that an rpm spec file is capturing but the rpc spec file would allow wrapping multi-step builds. > 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 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 (which > is something that MacPorts uses) wherein the actual package is created. So, > there end up being two installation trees: the staging area using during > packaging and the final destination when the package is installed. I guess I am missing something here. Why is the staging area ever needed. If you know you want to end up calling install with a destination path, why not just call install from the beginning and skip the first step? I think there must be a requirement here that I am just missing. > 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) >> 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. -Allen > This is something that I know I have > 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 installing >>> itself unless told to do so. >>> >>> The CppDOM build is in pretty bad shape and hasn't ever been quite what I >>> would call ideal. The installation part has never really worked correctly, >>> 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 well, >>> but the build certainly should support a two-step build+install process. >>> What version are you using? >>> >>> >>> >>>> I "fixed" the problem >>>> by adding guards in the scons files but that may not be the solution >>>> everyone is looking for. Thoughts? >>>> >>>> >>> What are guards in this context? >>> >>> -Patrick >>> > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > ------------------------------------------------------------------------ > > _______________________________________________ > Xml-cppdom-devel mailing list > Xml...@li... > https://lists.sourceforge.net/lists/listinfo/xml-cppdom-devel > |
