Skip to content
This repository has been archived by the owner on Jan 21, 2024. It is now read-only.

compilation options and platform #43

Open
montefra opened this issue Aug 17, 2016 · 4 comments
Open

compilation options and platform #43

montefra opened this issue Aug 17, 2016 · 4 comments

Comments

@montefra
Copy link
Contributor

@ericmandel: I have a couple of questions about xpa and the compilation and a meme to myself:

  1. why the xpa make uses the -DHAVE_CONFIG_H? Is it mandatory? I did try to remove it from pyds9/setup_packages.py but I get a lot of warnings about strncpy and others, notes about including string.h and an error in

    xpa.c:539:24 error: dereferencing pointer to incomplete type ``struct passwd``
         strncpy(nusers, pw->pw_name, SZ_line-1);
                            ^-
    

    If there is a way of avoiding -DHAVE_CONFIG_H, I might be able to build libxpa and xpans without needing to run ./configure and make distclean, which I might prefer. Right now I run configure just to create the conf.h file, as all the compilation options are in the setup_package.py.
    Any suggestion?

  2. pyds9 on windows: the current implementation will fail on windows. For some reason I modified _find_shlib and never reverted back to the original version. I also need to make Windows proofed the getting of xpans and ds9, using the original implementation. The xpa.py and pyds9.py files from commit a1fb025 should be good enough for it.

I hope that I managed to do it before going on vacation next week.

@ericmandel
Copy link
Owner

@montefra I don't see how you can avoid running configure, since it figures out platform-dependent configuration. For example, Mac OSX does not use malloc.h to declare the malloc calls (they are in stdlib.h, I think), whereas Linux does. So configure determines that and arranges to include malloc.h under Linux but not OSX. How would you handling this sort of difference without running configure and putting the results somewhere?

What do you need for Windows? I'm not sure what you are asking ...

@montefra
Copy link
Contributor Author

montefra commented Aug 17, 2016

@montefra I don't see how you can avoid running configure, since it figures out platform-dependent configuration. For example, Mac OSX does not use malloc.h to declare the malloc calls (they are in stdlib.h, I think), whereas Linux does. So configure determines that and arranges to include malloc.h under Linux but not OSX. How would you handling this sort of difference without running configure and putting the results somewhere?

I see.
A curiosity then: why the Makefile run the c compilier with -DHAVE_CONFIG_H? If you have to run configure and have #include "conf.h", what is the motivation to have an #ifdef HAVE_CONFIG_H?

What do you need for Windows? I'm not sure what you are asking ...

It's mostly a note for myself. If I have questions about it I'll let you know.

Thank you for the info

@ericmandel
Copy link
Owner

@montefra The -DHAVE_CONFIG_H is there because there are two ways to pass the config parameters to the C compiler: you can pass them in a config.h file or you can pass them on the command line directly. Would it help if we used the command-line technique? You would still have to run config (or generate the platform-dependent info in some way), but we could dispense with creating the config.h file. If you want to use that method, I can look into changing the xpa build in the next few days.

@montefra
Copy link
Contributor Author

@ericmandel : no need to modify xpa. Now I know and I'm happy.

Would it help if we used the command-line technique?

I'm not sure. I think it's easier run configure and pass -DHAVE_CONFIG_H than passing a bunch of arguments. Plus the current system is working (mostly) and I would not touch it if not necessary.

Thanks again for the clarification

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants