Re: github portgroup design
- On 25 Jun, 2015, at 03:19, Joshua Root j...@macports.org wrote: >> I like named args in Objective-C and Swift, but we haven't used them in setup >> procs, that I recall. We use them some in MacPorts base, yes? Need a good >> example to look at... > > The add_users option and its underlying adduser/addgroup procs are one > example that uses the = approach. And some more "native" to Tcl/Tk applications use the -name value approach. For example, glue code we generate using SWIG uses the following operations that are apparently similar to Tk widgets: To load: $ref cget -fieldname To store: $ref configure [-fieldname $value]... See some of the rev-upgrade code that uses this: http://trac.macports.org/browser/trunk/base/src/macports1.0/macports.tcl?marks=4621,4624,4627#L4618 and the SAT-solving GSoC branch uses configure: http://trac.macports.org/browser/branches/gsoc15-dependency/base/src/macports1.0/macports_libsolv.tcl?marks=100-102#L98 -- Clemens Lang ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [137995] trunk/dports/science
> On Jun 24, 2015, at 3:31 PM, take...@macports.org wrote:
>
> Revision
> 137995
> Author
> take...@macports.org
> Date
> 2015-06-24 13:31:21 -0700 (Wed, 24 Jun 2015)
> Log Message
>
> grib_api, libemos, magicspp: set CMAKE_INSTALL_NAME_DIR in grib_api, revbump
> ports that depends on grib_api
> --- trunk/dports/science/grib_api/Portfile2015-06-24 18:50:08 UTC (rev
> 137994)
> +++ trunk/dports/science/grib_api/Portfile2015-06-24 20:31:21 UTC (rev
> 137995)
> @@ -42,7 +43,8 @@
> fetch.ignore_sslcert yes
> cmake.out_of_source yes
>
> -configure.args -DENABLE_FORTRAN=OFF \
> +configure.args -DCMAKE_INSTALL_NAME_DIR=${prefix}/lib \
> +-DENABLE_FORTRAN=OFF \
> -DENABLE_NETCDF=ON \
> -DENABLE_PNG=ON \
> -DENABLE_PYTHON=OFF \
The cmake-1.0 portgroup sets CMAKE_INSTALL_NAME_DIR and other helpful
configure.args for you. To take advantage of them, all you have to do is append
to configure.args rather than overwrite it.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: github portgroup design
On 2015-6-25 10:56 , Ryan Schmidt wrote: > On Jun 23, 2015, at 7:01 PM, Joshua Root wrote: > >> On 2015-6-24 07:21 , Ryan Schmidt wrote: >>> >>> On Jun 22, 2015, at 4:42 PM, Lawrence Velázquez wrote: >>> On Jun 4, 2015, at 7:32 PM, Ryan Schmidt wrote: > I agree setup procs are not the best. I also don't like that the semantics of the arguments are not obvious. We might know from experience what the different components of github.setup foo bar 1.0 foo- mean, but it doesn't lend itself to being understood. And then each portgroup with a setup proc uses different arguments. >>> >>> Well sure, each portgroup has different needs. As long as the arguments are >>> documented, which they are for the github portgroup, that's at least >>> something. >> >> If we must have setup procs, their invocations should be readable. They >> should take named args, e.g. '-somearg foo -otherarg bar' or >> 'somearg=foo otherarg=bar'. > > I like named args in Objective-C and Swift, but we haven't used them in setup > procs, that I recall. We use them some in MacPorts base, yes? Need a good > example to look at... The add_users option and its underlying adduser/addgroup procs are one example that uses the = approach. - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: github portgroup design
On Jun 23, 2015, at 7:01 PM, Joshua Root wrote: > On 2015-6-24 07:21 , Ryan Schmidt wrote: >> >> On Jun 22, 2015, at 4:42 PM, Lawrence Velázquez wrote: >> >>> On Jun 4, 2015, at 7:32 PM, Ryan Schmidt wrote: >>> I agree setup procs are not the best. >>> >>> I also don't like that the semantics of the arguments are not obvious. We >>> might know from experience what the different components of >>> >>> github.setup foo bar 1.0 foo- >>> >>> mean, but it doesn't lend itself to being understood. And then each >>> portgroup with a setup proc uses different arguments. >> >> Well sure, each portgroup has different needs. As long as the arguments are >> documented, which they are for the github portgroup, that's at least >> something. > > If we must have setup procs, their invocations should be readable. They > should take named args, e.g. '-somearg foo -otherarg bar' or > 'somearg=foo otherarg=bar'. I like named args in Objective-C and Swift, but we haven't used them in setup procs, that I recall. We use them some in MacPorts base, yes? Need a good example to look at... ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: python: finding specific library version via CMake
On Wednesday June 24 2015 15:04:32 Mark Moll wrote: > Part of the problem is that there is no way to force the default CMake > modules for finding an python interpreter and python libraries to agree on > the same version. As a way around that I wrote my own FindPython.cmake: > > https://bitbucket.org/ompl/ompl/src/tip/CMakeModules/FindPython.cmake Ah, now that's something worth knowing, thanks! René. > > You can then specify a specific version: > > find_package(python 3.4) > > This will define PYTHON_EXEC, PYTHON_LIBRARIES, PYTHON_INCLUDE_DIRS, > PYTHON_SITE_MODULES, and PYTHON_VERSION. If you run cmake like so: > > cmake -DPYTHON_EXEC=/opt/local/bin/python3.4 .. > > then the other variables are automatically defined appropriately. > > You can also use it to find python modules: > > find_python_module(numpy [version] [REQUIRED|QUIET]) > > Best, > Mark ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: python: finding specific library version via CMake
Part of the problem is that there is no way to force the default CMake modules
for finding an python interpreter and python libraries to agree on the same
version. As a way around that I wrote my own FindPython.cmake:
https://bitbucket.org/ompl/ompl/src/tip/CMakeModules/FindPython.cmake
You can then specify a specific version:
find_package(python 3.4)
This will define PYTHON_EXEC, PYTHON_LIBRARIES, PYTHON_INCLUDE_DIRS,
PYTHON_SITE_MODULES, and PYTHON_VERSION. If you run cmake like so:
cmake -DPYTHON_EXEC=/opt/local/bin/python3.4 ..
then the other variables are automatically defined appropriately.
You can also use it to find python modules:
find_python_module(numpy [version] [REQUIRED|QUIET])
Best,
Mark
> On Jun 22, 2015, at 4:01 PM, René J.V. Bertin wrote:
>
> Hi,
>
> I have a CMake file that has the following, hopefully self-explanatory, bit:
>
> {{{
> find_package(PythonLibs 3.4.3 REQUIRED)
> if ( NOT ${PYTHONLIBS_FOUND} OR ${PYTHON_VERSION_MINOR} GREATER 4 )
>message(FATAL_ERROR "Python 3.4.3 with --enable-shared is required")
> endif()
> }}}
>
> The only thing that did was picking up an old 2.4.3 (!) framework I'd
> installed as /Library/Frameworks/Python2.4.framework; after removing that it
> finds nothing at all.
> I had a comparable issue with `find_package(PythonInterp 3.0 required)` which
> I could resolve by hardcoding the PYTHON_EXECUTABLE variable, but I don't
> think one can pull a similar trick with the PythonLibs script.
>
> Is there a clean way out, I'm surely not the first one to try this?
>
> Thanks,
> R.
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev
>
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: python: finding specific library version via CMake
On Tuesday June 23 2015 16:04:39 Ryan Schmidt wrote: > My impression is that cmake is horrible at many things, including finding > dependencies, and that you're best off bypassing automatic dependency finding > by specifying the absolute path to every dependency About that: how do I get the required information in my Portfile without including the python PortGroup which would redefine the build system completely in my experience? R. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
New port submissions - please commit
Can someone please have a look at these and commit? https://trac.macports.org/ticket/47823 https://trac.macports.org/ticket/48161 Thanks, Albert -- Dr. Albert Gr"af Computer Music Research Group, JGU Mainz, Germany Email: aggr...@gmail.com WWW:https://plus.google.com/+AlbertGraef ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: python: finding specific library version via CMake
On Tuesday June 23 2015 16:27:57 Ryan Schmidt wrote: > >On Jun 23, 2015, at 4:21 PM, René J.V. Bertin wrote: > >> Hairy detail: this project requires exactly Python 3.4.3 - nothing more, >> nothing less... > >I guess it'll work today, and break when the python34 port is updated to >3.4.4. Not a great requirement for a project to have. So say we all... I'm guessing they intend to address the requirement in time for 3.4.4; it's the other question I'm planning to ask... R ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
