[MacPorts] #49711: [cpp-netlib][0.11.2][new port]

MacPorts noreply at macports.org
Mon Dec 14 06:05:23 PST 2015


#49711: [cpp-netlib][0.11.2][new port]
-------------------------+--------------------------------
  Reporter:  nikkoara@…  |      Owner:  macports-tickets@…
      Type:  submission  |     Status:  new
  Priority:  Normal      |  Milestone:
 Component:  ports       |    Version:
Resolution:              |   Keywords:
      Port:  cpp-netlib  |
-------------------------+--------------------------------

Comment (by nikkoara@…):

 Replying to [comment:7 raimue@…]:
 > Regarding the `+static` variant, the port contents should not change
 depending on the variants selected on the boost port. This is an
 additional input that is not represented in the set of
 name/version/revision/epoch/variants. This means, users get different
 results depending on the installed boost library and users cannot use
 binary archives. Can the static libraries explicitly be disabled? Also,
 what would be built if I use both `-shared -static`?

 Disclaimer: my knowledge of Macports is limited.

 The CMake infrastructure of the cpp-netlib project builds either shared
 libraries or static libraries. It does not contain provisions to build
 both. The selection hinges entirely on the CMake macro BUILD_SHARED_LIBS:
 if on, it builds shared libs, etc. If this is considered to be a
 limitation from the Macports framework pov there is little I can do about
 it.

 The selection of static/shared libraries must match the kind of Boost
 libraries that are installed on the target machine, which is why I added
 the check inside the +static block. IMO it makes no sense to install the
 port with -static -shared. IIUC that means build without static and
 without shared variants? How does that work for libraries?

 >
 > Compilation failed on my system. I am no CMake expert and have no idea
 where to look further for this. I did not see any mention of the problem
 in `CMakeOutput.log`, but if required I could provide it.

 Could you please attach that and your invocation of ports? I would like to
 take a look at it.

 >
 > Also, as another suggestion, I would reorder the options in the Portfile
 in the order they are required for the fetch/patch/configure/build phases.
 I attached an updated version, but leave the final decision on this to you
 as proposed maintainer.

 I have no problem with that.

 Thanks!

-- 
Ticket URL: <https://trac.macports.org/ticket/49711#comment:8>
MacPorts <https://www.macports.org/>
Ports system for OS X


More information about the macports-tickets mailing list