|
Home > Archive > Unix Programming > February 2007 > detect compile environment
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
detect compile environment
|
|
| Bill Waddington 2007-02-07, 7:23 pm |
| [noob alert!]
Sorry I haven't been able to google up an answer to this. It
must be a common question...
I have a little sockets app that can be compiled on various
unixen - and windows - with fairly small differences in the
#defines and #includes.
I will zip up a few binaries, but since the zip will include
source I want to make it simple for a user to modify and
rebuild the app as needed.
Is there an easy way to #ifdef the compile platform after
#include(ing) a header common to all of the above? I can
have the user do a -D__SOLARIS__ or whatever during the
compile, but it seems like there should be an auto way.
Thanks,
Bill
--
William D Waddington
william.waddington@beezmo.com
"Even bugs...are unexpected signposts on
the long road of creativity..." - Ken Burtch
| |
| Pascal Bourguignon 2007-02-07, 7:23 pm |
| Bill Waddington <william.waddington@beezmo.com> writes:
> [noob alert!]
>
> Sorry I haven't been able to google up an answer to this. It
> must be a common question...
>
> I have a little sockets app that can be compiled on various
> unixen - and windows - with fairly small differences in the
> #defines and #includes.
>
> I will zip up a few binaries, but since the zip will include
> source I want to make it simple for a user to modify and
> rebuild the app as needed.
>
> Is there an easy way to #ifdef the compile platform after
> #include(ing) a header common to all of the above? I can
> have the user do a -D__SOLARIS__ or whatever during the
> compile, but it seems like there should be an auto way.
You can use uname to get some idea about the system where you are.
case $(uname) in
Linux) ... ;;
Darwin) ... ;; # MacOSX too
*) echo unknown system ;;
esac
uname -m
gives the machine hardware. eg i686 on an Athlon processor.
--
__Pascal Bourguignon__ http://www.informatimago.com/
CONSUMER NOTICE: Because of the "uncertainty principle," it is
impossible for the consumer to simultaneously know both the precise
location and velocity of this product.
| |
| Bill Waddington 2007-02-07, 7:23 pm |
| On Wed, 07 Feb 2007 20:39:54 +0100, Pascal Bourguignon
<pjb@informatimago.com> wrote:
>Bill Waddington <william.waddington@beezmo.com> writes:
[vbcol=seagreen]
>
>You can use uname to get some idea about the system where you are.
>
>case $(uname) in
>Linux) ... ;;
>Darwin) ... ;; # MacOSX too
>*) echo unknown system ;;
>esac
>
>uname -m
>gives the machine hardware. eg i686 on an Athlon processor.
Thanks. That works for any _real_ OS. I was trying to keep
the detection _inside_ the source module(s) <OT> so it might
work with that other OS as well </OT> so the user could just
invoke the available compiler directly.
Thanks again,
Bill
--
William D Waddington
william.waddington@beezmo.com
"Even bugs...are unexpected signposts on
the long road of creativity..." - Ken Burtch
| |
| boa sema 2007-02-07, 7:23 pm |
| Bill Waddington wrote:
> On Wed, 07 Feb 2007 20:39:54 +0100, Pascal Bourguignon
> <pjb@informatimago.com> wrote:
>
>
>
>
>
>
>
>
> Thanks. That works for any _real_ OS. I was trying to keep
> the detection _inside_ the source module(s) <OT> so it might
> work with that other OS as well </OT> so the user could just
> invoke the available compiler directly.
>
> Thanks again,
> Bill
Check out http://predef.sourceforge.net/
Boa
| |
| Giorgos Keramidas 2007-02-07, 7:23 pm |
| On Wed, 07 Feb 2007 11:58:36 -0800, Bill Waddington <william.waddington@beezmo.com> wrote:
>On Wed, 07 Feb 2007 20:39:54 +0100, Pascal Bourguignon
><pjb@informatimago.com> wrote:
>
> Thanks. That works for any _real_ OS. I was trying to keep
> the detection _inside_ the source module(s) <OT> so it might
> work with that other OS as well </OT> so the user could just
> invoke the available compiler directly.
You can use one of the systems which are meant to `automate' this
process, i.e. the autoconf, automake, and libtool suite of tools.
You can write your Makefiles in POSIX-make(1)-only style, and set
up little 'workspace activation' scripts to predefine environment
variables for make(1).
You can even write separate build.sh/build.bat/build.whatever
scripts, and so on...
What you may have to consider in the process of designing a
'portable' build procedure are, at least, the following:
* The target operating system type.
* The target operating system version.
* The compiler suite and its version.
* The target architecture.
* What build-tools are 'prerequisites', for your process.
| |
| Ivan Novick 2007-02-07, 7:23 pm |
| On Feb 7, 12:37 pm, Giorgos Keramidas <keram...@ceid.upatras.gr>
wrote:
> On Wed, 07 Feb 2007 11:58:36 -0800, Bill Waddington <william.wadding...@beezmo.com> wrote:
>
>
>
>
>
> You can use one of the systems which are meant to `automate' this
> process, i.e. the autoconf, automake, and libtool suite of tools.
>
> You can write your Makefiles in POSIX-make(1)-only style, and set
> up little 'workspace activation' scripts to predefine environment
> variables for make(1).
>
> You can even write separate build.sh/build.bat/build.whatever
> scripts, and so on...
>
> What you may have to consider in the process of designing a
> 'portable' build procedure are, at least, the following:
>
> * The target operating system type.
>
> * The target operating system version.
>
> * The compiler suite and its version.
>
> * The target architecture.
>
> * What build-tools are 'prerequisites', for your process.- Hide quoted text -
>
> - Show quoted text -
Doesn't the C preprocessor define variables for this too?
Try running this:
touch foo.h; cpp -dM foo.h
Ivan Novick
http://www.0x4849.net
| |
| Billy Patton 2007-02-08, 1:19 pm |
| I don't deal with wondoze but I do have to deal with solaris vs linux.
May this will give you a starting place
In my makefile i use
# determine the platform SunOS or Linux
define Cpu_type
if [ `/bin/uname -s` = 'SunOS' ] ; then echo SunOS ; \
elif [ `/bin/uname -s` = 'Linux' ] ; then echo Linux ; \
fi
endef
# determine is system is 64 or 32 bit
define Bit_size
if [ `/bin/uname -s` = 'Linux' ] ; then \
if [ `/bin/uname -m` = 'x86_64' ] ; then echo 64 ; \
else echo 32; \
fi; \
elif [ `/bin/uname -s` = 'SunOS' ] ; then \
if [ `/bin/isainfo -b` = 64 ] ; then echo 64; \
else echo 32; \
fi; \
fi
endef
BIT = $(shell $(Bit_size))
CPU = $(shell $(Cpu_type))
You could just as easily modify these to set the -D${CPU}
"Bill Waddington" <william.waddington@beezmo.com> wrote in message
news:169ks25sod5gq6itgp2m5g14mtfdf4bo0k@
4ax.com...
> [noob alert!]
>
> Sorry I haven't been able to google up an answer to this. It
> must be a common question...
>
> I have a little sockets app that can be compiled on various
> unixen - and windows - with fairly small differences in the
> #defines and #includes.
>
> I will zip up a few binaries, but since the zip will include
> source I want to make it simple for a user to modify and
> rebuild the app as needed.
>
> Is there an easy way to #ifdef the compile platform after
> #include(ing) a header common to all of the above? I can
> have the user do a -D__SOLARIS__ or whatever during the
> compile, but it seems like there should be an auto way.
>
> Thanks,
> Bill
> --
> William D Waddington
> william.waddington@beezmo.com
> "Even bugs...are unexpected signposts on
> the long road of creativity..." - Ken Burtch
|
|
|
|
|