Re: About libdir for 64-bit

2013-08-24 Thread Mike Frysinger 
On Thursday 18 July 2013 19:51:51 Russ Allbery wrote:
 It doesn't -- but neither of those use the lib64/lib32 layout either,
 because that layout can't represent that difference.  They do something
 more complicated (they have to).  So basically it's out of scope for what
 my macro is trying to solve (and what the original question asked for,
 also).

i don't think it is.  you're trying to guess the default multilib dir.  x32 is 
another x86 related multilib (it installs into libx32 ... not complicate at 
all).  the mips example isn't limited to IRIX; Linux supports them too.  also 
assuming how the system has configured things based purely on tuples is a good 
way to fail.

asking the compiler (gcc) for its multilib OS path is the closest atm to 
reliably getting the right answer.
-mike


signature.asc
Description: This is a digitally signed message part.
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Re: CPPFLAGS and config.h needed by dependent projects?

2013-08-24 Thread Mike Frysinger 
On Wednesday 31 July 2013 11:16:27 Nate Bargmann wrote:
 * On 2013 31 Jul 08:03 -0500, LRN wrote:
  On 31.07.2013 16:17, Daniel Pocock wrote:
   Should we be distributing a config script, e.g. bin/xxx-config that can
   emit CPPFLAGS?
  
  Either that, or distribute a .pc file for pkg-config (and appropriate
  .m4 for dependent projects to use, if you don't have these already).
 
 I'll concur as the Hamlib project only installs the public headers, none
 of which depend on config.h, and a hamlib.pc and hamlib.m4 file.  I have
 yet to receive a request from any of our consumers to know what *FLAGS
 were used.  To be clear, the only binaries the project provide are for
 Windows and the free OS distributions build their own binaries.
 
 As I understand it, config.h is a snapshot of the build system at
 configure time.  After a few upgrades of the build system it may well be
 out of date and require a configure run to update it.  We've tried to
 adhere to a policy that the public API should not depend on a localized
 configuration.

at the risk of just adding noise, everything Nate has sad is correct and you 
should listen to him ;)
-mike


signature.asc
Description: This is a digitally signed message part.
___
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf