#17995 closed defect (fixed)
mesa 7.2 does not build due to incomplete configuration
Reported by: | pgijnxn02@… | Owned by: | jeremyhu (Jeremy Huddleston Sequoia) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 1.7.0 |
Keywords: | Cc: | andrea.damore@…, trog24 (Frank J. R. Hanstick) | |
Port: | mesa |
Description
Tiger 10.4.11 Mac Mini PPC
Something (gnucash or qt3?) is pulling in mesa as a dependency when I upgrade. It doesn't build, apparently because it's using "default" as a make target when it needs to be something else from a list it gives.
---> Building mesa DEBUG: Executing org.macports.build (mesa) DEBUG: Environment: MACOSX_DEPLOYMENT_TARGET='10.4' DEBUG: Assembled command: 'cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_x11_mesa/work/Mesa-7.2" && nice -n 10 make default INSTALL_DIR=/opt/local X11_DIR=/opt/local' Please choose a configuration from the following list: aix aix-64 aix-64-static aix-gcc aix-static beos bluegene-osmesa bluegene-xlc-osmesa catamount-osmesa-pgi config.mgw darwin darwin-fat-32bit darwin-fat-all freebsd [etc] Then type 'make <config>' (ex: 'make linux-x86') Or, run './configure' then 'make' See './configure --help' for details (ignore the following error message) make: *** [configs/current] Error 1
However, substituting "darwin" for default does not cause it to build correctly. I see that the Porfile has "use_configure no" set. Is that skipping a necessary configuration step?
Change History (5)
comment:1 Changed 16 years ago by jmroot (Joshua Root)
Cc: | andrea.damore@… added |
---|---|
Owner: | changed from macports-tickets@… to jeremyhu@… |
comment:2 Changed 16 years ago by blb@…
comment:4 Changed 16 years ago by jeremyhu (Jeremy Huddleston Sequoia)
Resolution: | → fixed |
---|---|
Status: | new → closed |
Note: See
TracTickets for help on using
tickets.
Shouldn't the post-extract be testing for configs/darwin, not configs/current (since current won't exist just after an extract)?
Also, should X11_DIR be set to ${prefix} instead of ${x11prefix} as the latter would be taken care of with the system_x11 variant?