March 2015 - macports-tickets - lists.macosforge.org

Re: [MacPorts] #33259: cmake portgroup: out of source build option, possibly by default
by MacPorts 10 Mar '15

10 Mar '15

#33259: cmake portgroup: out of source build option, possibly by default ---------------------------+-------------------------------- Reporter: ryandesign@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: | ---------------------------+-------------------------------- Comment (by cal@…): I'd rather shorten the option name to `cmake.out_of_source` and use `yes` and `no` over `true` and `false` like we usually do. Your code only allows `true`, which is bad, because maintainers will try to set it to `yes` or `1`. Also, I'd rather modify the defaults than change the actual values when `cmake.out_of_source yes` is encountered in a Portfile. That would make {{{ configure.dir ${worksrcpath}/foo cmake.out_of_source yes }}} work correctly. It's not obvious which side effects assigning to out_of_source has, otherwise. -- Ticket URL: <https://trac.macports.org/ticket/33259#comment:21> MacPorts <https://www.macports.org/> Ports system for OS X

1 0

Re: [MacPorts] #33259: cmake portgroup: out of source build option, possibly by default
by MacPorts 10 Mar '15

10 Mar '15

#33259: cmake portgroup: out of source build option, possibly by default ---------------------------+-------------------------------- Reporter: ryandesign@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: | ---------------------------+-------------------------------- Comment (by mojca@…): I did some very very basic testing, but I couldn't get the code to work in the way it was written even after removing the typos and obvious problems. I suspect the problem is that {{{ if {${cmake.build_out_of_source}} { }}} is only evaluated once. And the setting {{{ cmake.build_out_of_source true }}} after importing the PortGroup has no effect whatsoever. I assume that this should be a procedure rather than a setting. Here's a draft that worked for me with at least one port: {{{ options cmake.build_out_of_source option_proc cmake.build_out_of_source cmake._set_out_of_source_build proc cmake._set_out_of_source_build {option action args} { global workpath worksrcpath configure.dir build.dir if {"set" ne ${action}} { return } if {${args} eq "true"} { configure.dir ${workpath}/build build.dir ${configure.dir} # standard post-arg, where the primary CMakeLists.txt file can be found configure.post_args ${worksrcpath} # create the build directory post-extract { file mkdir ${build.dir} } } } }}} I was copy-pasting from another PortGroup, so I'm not sure if I actually got all the bits and pieces right. -- Ticket URL: <https://trac.macports.org/ticket/33259#comment:20> MacPorts <https://www.macports.org/> Ports system for OS X

1 0

Re: [MacPorts] #25905: [NEW] graphics/*picviz*
by MacPorts 10 Mar '15

10 Mar '15

#25905: [NEW] graphics/*picviz* -------------------------------------------------+------------------------- Reporter: jul_bsd@… | Owner: Type: submission | ryandesign@… Priority: Normal | Status: assigned Component: ports | Milestone: Resolution: | Version: 1.9.1 Port: libpicviz, picviz-cli, picviz-gui, | Keywords: py26-libpicviz | -------------------------------------------------+------------------------- Comment (by jul_bsd@…): Just a quick update. it doesn't compile anymore on macos10.10. seems a libevent problem {{{ /usr/bin/clang -Wall -Wextra -O0 -ggdb -g -arch x86_64 -mmacosx-version- min=10.10 -dynamiclib -Wl,-headerpad_max_install_names -lm -lfl -ly -L /opt/local/lib -lpcre -compatibility_version 2.0.0 -o libpicviz.2.dylib -install_name /opt/local/lib/libpicviz.2.dylib CMakeFiles/picviz.dir/axis.c.o CMakeFiles/picviz.dir/axisplot.c.o CMakeFiles/picviz.dir/correlation.c.o CMakeFiles/picviz.dir/debug.c.o CMakeFiles/picviz.dir/real-time.c.o CMakeFiles/picviz.dir/filter.c.o CMakeFiles/picviz.dir/image.c.o CMakeFiles/picviz.dir/learn.c.o CMakeFiles/picviz.dir/line.c.o CMakeFiles/picviz.dir/pgdl.c.o CMakeFiles/picviz.dir/plugins.c.o CMakeFiles/picviz.dir/engine.c.o CMakeFiles/picviz.dir/picviz-hash.c.o CMakeFiles/picviz.dir/picviz- init.c.o CMakeFiles/picviz.dir/picviz-pcre.c.o CMakeFiles/picviz.dir/properties.c.o CMakeFiles/picviz.dir/render.c.o CMakeFiles/picviz.dir/values-mapping.c.o CMakeFiles/picviz.dir/variable.c.o CMakeFiles/picviz.dir/utils.c.o CMakeFiles/picviz.dir/filter-parser.c.o CMakeFiles/picviz.dir/filter- lexer.c.o CMakeFiles/picviz.dir/pgdl-parser.c.o CMakeFiles/picviz.dir /pgdl-lexer.c.o CMakeFiles/picviz.dir/prop-color.c.o -L/opt/local/var/macports/build/_Users_julien_tmp_myports_graphics_libpicviz/libpicviz/work /picviz-latest/libpicviz/libev -lm -ldl -L/opt/local/var/macports/build/_Users_julien_tmp_myports_graphics_libpicviz/libpicviz/work /picviz-latest/libpicviz/libev/ -lev -Wl,-rpath,/opt/local/lib Undefined symbols for architecture x86_64: "_ev_default_loop_init", referenced from: _ev_default_loop in real-time.c.o "_ev_loop", referenced from: _picviz_fifo_data_read in real-time.c.o "_ev_unloop", referenced from: _picviz_fifo_cb in real-time.c.o ld: symbol(s) not found for architecture x86_64 }}} -- Ticket URL: <https://trac.macports.org/ticket/25905#comment:9> MacPorts <https://www.macports.org/> Ports system for OS X

1 0

[MacPorts] #46638: clang 3.5 sanitizer (ubsan) does not work
by MacPorts 10 Mar '15

10 Mar '15

#46638: clang 3.5 sanitizer (ubsan) does not work --------------------+-------------------------------- Reporter: uri@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Keywords: | Port: clang-3.5 --------------------+-------------------------------- Mac OS X 10.9.5, Xcode-6.1.1, Macports-2.3.3. Macports-installed "clang-3.5 +analyzer +arm_runtime +assertions" doesn't build ubsan completely or correctly. As a result, compiling/linking a program with "-fsanitize=undefined -fsanitized=address" succeeds in producing an executable: {{{ $ clang++-mp-3.5 -v -fsanitize=undefined -fsanitize=address -o tj tj.cpp -lc++ -lc++abi clang version 3.5.1 (tags/RELEASE_351/final) Target: x86_64-apple-darwin13.4.0 Thread model: posix "/opt/local/libexec/llvm-3.5/bin/clang" -cc1 -triple x86_64-apple- macosx10.9.0 -emit-obj -mrelax-all -disable-free -main-file-name tj.cpp -mrelocation-model pic -pic-level 2 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 236.3 -v -dwarf- column-info -resource-dir /opt/local/libexec/llvm-3.5/bin/../lib/clang/3.5.1 -stdlib=libc++ -fdeprecated-macro -fdebug-compilation-dir /Users/uri/src -ferror-limit 19 -fmessage-length 84 -fsanitize=address,alignment,array-bounds,bool,enum ,float-cast-overflow,float-divide-by-zero,integer-divide-by-zero,null ,object-size,return,shift,signed-integer-overflow,unreachable,vla- bound,vptr -stack-protector 1 -mstackrealign -fblocks -fobjc- runtime=macosx-10.9.0 -fencode-extended-block-signature -fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o /var/folders/pd/mxn5kp_55jg23x7jjd10gtwm0000gn/T/tj-65dfdd.o -x c++ tj.cpp clang -cc1 version 3.5.1 based upon LLVM 3.5.1 default target x86_64 -apple-darwin13.4.0 ignoring nonexistent directory "/usr/include/c++/v1" #include "..." search starts here: #include <...> search starts here: /opt/local/libexec/llvm-3.5/bin/../include/c++/v1 /usr/local/include /opt/local/libexec/llvm-3.5/bin/../lib/clang/3.5.1/include /usr/include /System/Library/Frameworks (framework directory) /Library/Frameworks (framework directory) End of search list. "/opt/local/libexec/llvm-3.5/bin/ld" -demangle -dynamic -arch x86_64 -macosx_version_min 10.9.0 -o tj /var/folders/pd/mxn5kp_55jg23x7jjd10gtwm0000gn/T/tj-65dfdd.o -lc++ -lc++abi -lc++ /opt/local/libexec/llvm-3.5/bin/../lib/clang/3.5.1/lib/darwin/libclang_rt.ubsan_osx.a -lc++ -lc++ /opt/local/libexec/llvm-3.5/bin/../lib/clang/3.5.1/lib/darwin/libclang_rt.asan_osx_dynamic.dylib -lSystem /opt/local/libexec/llvm-3.5/bin/../lib/clang/3.5.1/lib/darwin/libclang_rt.osx.a }}} But that executable does not run correctly, complaining about vptr: {{{ /opt/local/libexec/llvm-3.5/bin/../include/c++/v1/streambuf:273:12: runtime error: member call on address 0x7fff7b62f068 which does not point to an object of type 'std::__1::basic_streambuf<char, std::__1::char_traits<char> >' 0x7fff7b62f068: note: object is of type 'std::__1::__stdoutbuf<char>' 00 00 00 00 10 05 63 7b ff 7f 00 00 70 fc 62 7b ff 7f 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ^~~~~~~~~~~~~~~~~~~~~~~ vptr for 'std::__1::__stdoutbuf<char>' }}} Compiling with "-fno-sanitize=vptr" produces an executable that runs perfectly: {{{ $ clang++-mp-3.5 -fsanitize=undefined -fsanitize=address -fno- sanitize=vptr -o tj tj.cpp -lc++ -lc++abi $ ./tj This is a test $ }}} CFE-DEV people explained that the problem is with UBSan, as it seems (to them) to be built without RTTI support. I tried to build clang-3.5 by myself from scratch (no Macports patches), and it appears fully functional, at least with respect to analyzers. But I'd much rather use standard maintainable port like yours. Could you point me at what is done differently to UBSan in Macports version of clang-3.5, and how (or better yet - you :) I could undo it? Maybe as a port variant? Thanks! -- Ticket URL: <https://trac.macports.org/ticket/46638> MacPorts <https://www.macports.org/> Ports system for OS X

1 7

Re: [MacPorts] #33259: cmake portgroup: out of source build option, possibly by default
by MacPorts 10 Mar '15

10 Mar '15

#33259: cmake portgroup: out of source build option, possibly by default ---------------------------+-------------------------------- Reporter: ryandesign@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: | ---------------------------+-------------------------------- Comment (by mojca@…): Replying to [comment:14 rjvbertin@…]: > {{{ > +options cmake.build_out_of_source > +default cmake.build_out_of_source false > + > +if {cmake.build_out_of_source} { > + # setup all ports using cmake to build in a separate directory from the source; > + # this setting must be the full directory path > + post-extract { file mkdir ${workpath}/build } > + > + # standard post-arg, where to find the primary CMakeLists.txt file. > + default configure.post_args {../${worksrcdir}} > + default configure.dir {${workpath}/build} > + default build.dir {${workpath}/build} > +} > }}} What is the role of the "`default`" keyword in "`default build.dir`" for example? Couldn't it be left out? -- Ticket URL: <https://trac.macports.org/ticket/33259#comment:19> MacPorts <https://www.macports.org/> Ports system for OS X

1 0

[MacPorts] #47083: dblatex fails with titlesec.sty not found error
by MacPorts 10 Mar '15

10 Mar '15

#47083: dblatex fails with titlesec.sty not found error ------------------------------+-------------------------------- Reporter: Joel.Brogniart@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Keywords: | Port: dblatex ------------------------------+-------------------------------- Since, r132311 dblatex fails to output a pdf file with a titlesec.sty not found error. To reproduce: {{{ # First clean macports to only get essential dependencies sudo port uninstall installed # Then install dblatex sudo port install dblatex }}} Create a simple test.xml file with ie.: {{{ <?xml version="1.0" encoding="UTF-8" standalone="no"?> <!DOCTYPE section PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis- open.org/docbook/xml/4.2/docbookx.dtd" [ ]> <article class="techreport" status="final"> <para>Just some blabla.</para> </article> }}} Then use dblatex to create a pdf file from this file: {{{ dblatex test.xml }}} The pdf creation fails. -- Ticket URL: <https://trac.macports.org/ticket/47083> MacPorts <https://www.macports.org/> Ports system for OS X

1 4

Re: [MacPorts] #33259: cmake portgroup: out of source build option, possibly by default
by MacPorts 10 Mar '15

10 Mar '15

#33259: cmake portgroup: out of source build option, possibly by default ---------------------------+-------------------------------- Reporter: ryandesign@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: | ---------------------------+-------------------------------- Comment (by michaelld@…): I think we can add the option to cmake-1.0.tcl, as Rene has done. I won't have time to test until tomorrow, so if your tests work Mojca I'd say go ahead and commit the patch. -- Ticket URL: <https://trac.macports.org/ticket/33259#comment:18> MacPorts <https://www.macports.org/> Ports system for OS X

1 0

Re: [MacPorts] #33259: cmake portgroup: out of source build option, possibly by default
by MacPorts 10 Mar '15

10 Mar '15

#33259: cmake portgroup: out of source build option, possibly by default ---------------------------+-------------------------------- Reporter: ryandesign@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: | ---------------------------+-------------------------------- Comment (by mojca@…): If we change just `cmake-1.0.tcl`, we don't need to wait for a new release. But if we would introduce a global variable (that could also be used for `configure`-based projects), we might need an upgrade of base (not sure about that). Rene's last patch looks promising. I will test it on some of my ports. -- Ticket URL: <https://trac.macports.org/ticket/33259#comment:17> MacPorts <https://www.macports.org/> Ports system for OS X

1 0

Re: [MacPorts] #33259: cmake portgroup: out of source build option, possibly by default
by MacPorts 10 Mar '15

10 Mar '15

#33259: cmake portgroup: out of source build option, possibly by default ---------------------------+-------------------------------- Reporter: ryandesign@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: | ---------------------------+-------------------------------- Comment (by michaelld@…): Replying to [comment:15 mojca@…]: > What's the best way to introduce a new global variable (if we can agree on that and its name)? Does one need to upgrade MacPorts for the change to take effect? (If we would need an upgrade, it might be better to first introduce in the CMake PortGroup nevertheless and then move it to a global place once a new release comes to the horizon.) Good question. I'm not sure of the answer. Since the change is going into the PortGroup, I think it'll become part of user's install when they "selfupdate" or "sync", which means we can start using the variable immediately in Portfiles. I might be wrong though. Hopefully someone else knows for sure. -- Ticket URL: <https://trac.macports.org/ticket/33259#comment:16> MacPorts <https://www.macports.org/> Ports system for OS X

1 0

Re: [MacPorts] #33259: cmake portgroup: out of source build option, possibly by default
by MacPorts 10 Mar '15

10 Mar '15

#33259: cmake portgroup: out of source build option, possibly by default ---------------------------+-------------------------------- Reporter: ryandesign@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: | ---------------------------+-------------------------------- Comment (by mojca@…): There's another aspect that I forgot about. Thanks for pointing it out. Once we do the necessary changes globally or in the PortGroup we could simply change the individual CMake-based ports to opt-in one-by-one. Then a single commit would just set the variable default to ON in the CMake PortGroup (and next commit would just remove all those opt-ins in CMake- based ports). Then we wouldn't have any pressure or fears of unexpected failures. What's the best way to introduce a new global variable (if we can agree on that and its name)? Does one need to upgrade MacPorts for the change to take effect? (If we would need an upgrade, it might be better to first introduce in the CMake PortGroup nevertheless and then move it to a global place once a new release comes to the horizon.) -- Ticket URL: <https://trac.macports.org/ticket/33259#comment:15> MacPorts <https://www.macports.org/> Ports system for OS X

1 0