Writing "absolutely" portable code

[ArifulHossain tuhin]

I've posted a question regarding autoconf earlier where several people suggested avoiding "autoconf" altogether. I can generalize the suggestion by saying "avoiding" the whole "Autotools" chain. Interestingly i've come in contact with some recent opensource project which does not has any configure script. example : kamailio(www.kamilio.org).

We are trying to build a "very" portable library. The range it should support is, from intel stuffs to arm processors(in Iphone, android devices). If possible "symbian" from nokia will also be in the list of supported platform. I think Iphone/Android devices, being derivative of *nix platform, porting will be rather easy. even for windows environment we can ensure portability through cygwin/mingw. I'm not sure about "symbian" being anything near "POSIX".

Any pointer about the development process will be very helpful. I absolutely hate gnu autotools. If we can avoid it, it will be less pain in the back.

The library we want to build will include reference implementation of several RFCS, related to "SIP", "RTP", and also a media engine which will managesome codecs.

Thanks in advance

 

[ec429]

I've posted a question regarding autoconf earlier where several people suggested avoiding "autoconf" altogether. I can generalize the suggestion by saying "avoiding" the whole "Autotools" chain. Interestingly i've come in contact with some recent opensource project which does not has any configure script. example : kamailio(www.kamilio.org).

We are trying to build a "very" portable library. The range it should support is, from intel stuffs to arm processors(in Iphone, android devices). If possible "symbian" from nokia will also be in the list of supported platform. I think Iphone/Android devices, being derivative of *nix platform, porting will be rather easy. even for windows environment we can ensure portability through cygwin/mingw. I'm not sure about "symbian" being anything near "POSIX".

Any pointer about the development process will be very helpful. I absolutely hate gnu autotools. If we can avoid it, it will be less pain in the back.

The library we want to build will include reference implementation of several RFCS, related to "SIP", "RTP", and also a media engine which will manage some codecs.

Thanks in advance

Strictly follow POSIX and the C99 standard. Avoid using
compiler-specific extensions. Don't rely on the sizes of integer types;
if you need an N-bit int, use intN_t. If you need, for instance,
strndup, have some #ifdef-ed code that provides a replacement if it's
not present in the standard library. Hand-make a configure script that
tests for the things you need (by compiling and running tiny C programs)
and outputs that information into a file that gets included by your
Makefile (and defines some variable to hold some -D macro definitions
for the cpp). Hand-roll your makefile too, using implicit rules (%, $<
and $@ are your friends), but if some targets don't support GNU make,
you may need to write a tool to generate an explicit makefile from your
implicit rules (such a tool would be easier to write in, say, perl, than
in C).

Making software portable to Symbian is difficult, a losing game, and
probably not worthwhile (Symbian will probably be dead soon anyway).
There exists "P.I.P.S Is Posix on Symbian" which may help, but according
to Wiki it lacks signals and asynch IO.
A reference implementation of RFCs probably does not need to be portable
to Symbian in any case; my suggestion would be that a Symbian
implementation should be a separate project. It is (so I gather) so
different to POSIX-like systems that the gyrations needed to make the
same code run on both platforms would impede the readability of the code
(which is important for reference imps).

On the more general note of avoiding Autotools, I would note that all my
open-source projects (there are several) use hand-written Makefiles,
none has a configure script, and I have yet to encounter anything more
severe than a few #ifdef WINDOWS to handle cross-compilation to that
platform (and separate make rules for Windows targets). With a
cross-compiling gcc, even Cygwin is not necessary (although it would be
if you wanted to /compile/ on Windows).

-e

 

[Rui Maciel]

I absolutely hate gnu autotools. If we can avoid it, it will be less pain
in the back.

Why do you hate autotools? To me, any suggestion to avoid a tool in such
absolutist terms is unreasonable.


Rui Maciel

 

[jacob navia]

Le 09/01/12 11:26, ArifulHossain tuhin a écrit :

We are trying to build a "very" portable library.

The range it should support is, from intel stuffs to arm processors(in
Iphone, ...


Look I develop for iPhone. Forget about any kind of makefile that you
have since:

1) An iphone Application can only be developed using the XCode IDE of
Apple.

2) The IDE is responsible for compiling and loading your application
into the phone for debugging. This involves a dedicated iPhone/Mac
connection (yes, you will have to buy a Mac) and obtaining a certificate
from Apple that allows you to download stuff to the iPhone. All this
process is completely unique to Apple and there will be no possibility
of using any homegrown make process.

3) On the bright side developing for the phone is very easy since
objective C is a nice language, and if you use the objective C and C99
combination you will have the best of two very good worlds. The
compiler is standard (Apple's version of gcc) and very good.

Have fun with your phone... I was given one by the customer I worked
for, and it is the first time I can use my development system target
to do something other than the app I am developing!

 

[Jens Gustedt]

Am 01/09/2012 12:47 PM, schrieb ec429:

Strictly follow POSIX and the C99 standard. Avoid using
compiler-specific extensions. Don't rely on the sizes of integer types;
if you need an N-bit int, use intN_t. If you need, for instance,
strndup, have some #ifdef-ed code that provides a replacement if it's
not present in the standard library. Hand-make a configure script that
tests for the things you need (by compiling and running tiny C programs)
and outputs that information into a file that gets included by your
Makefile (and defines some variable to hold some -D macro definitions
for the cpp).

I'd subscribe to all of that.

Perhaps one addition, POSIX has getconf that can provide you
with valuable information about your target platform.

Jens

 

[Stefan Ram]

objective C is a nice language, and if you use the objective C and C99

Objective C is off-topic here, so I assume we are talking about C.

1) An iphone Application can only be developed using the XCode IDE of
Apple.

One can always split the code into two parts:

- a portable (»algorithmic«) part, that just assumes a standard
C implementation

- and the rest,

trying to make the first part as large as possible.

The first part then is absolutely portable, the rest needs
to be tuned to an environment.

 

[ec429]

One can always split the code into two parts:
- a portable (»algorithmic«) part, that just assumes a standard
C implementation
- and the rest,
trying to make the first part as large as possible.

This is a good idea even if you don't care about portability, actually.
Your interface should be as weakly coupled to your implementation as
is practical.
OTOH note that the OP said he was developing a library, so probably
isn't going to be writing any UI code anyway. The networking part is
going to have some "and the rest" in it, but if you have BSD sockets
then you're fine.
Then again, if iPhone is as painfully locked down as jacob suggests, it
might be better to just not support it - a platform that closed is not
going to thrive anyway.
-e

 

[Nick Keighley]

Then again, if iPhone is as painfully locked down as jacob suggests, it
might be better to just not support it - a platform that closed is not
going to thrive anyway.

hence Apples current poor performance...

 

[jacob navia]

Le 09/01/12 14:11, ec429 a écrit :

OTOH note that the OP said he was developing a library, so probably
isn't going to be writing any UI code anyway. The networking part is
going to have some "and the rest" in it, but if you have BSD sockets
then you're fine.
Then again, if iPhone is as painfully locked down as jacob suggests, it
might be better to just not support it - a platform that closed is not
going to thrive anyway.
-e

It is not as bad as it looks.

If you have no interaction with the iphone UI, you do not need Objective
C, and you can compile from the command line using
a normal makefile. The problem is that you will need to debug
your code and THAT needs XCode and the iphone connection.

I have ported and worked in a QT port to the iphone, and I
worked exclusively with the make environment of QT and their
source code using the command line in my Mac.

Since I was producing a library, I just included the library
into the user interface of my app. The library could be
debugged using the XCode debugger (that is actually just
a hacked version of gdb by Apple).

Having a Mac is not that of a big deal: a "mini" mac starts at around
600 euros in the apple store, not a big deal. And, I am very happy with
it:

I have come to the best Unix that I know of: nice, good looking,
easy to use, everything works, powerful, etc It is a
nice change after all those years under windows.

This closed environment is a god thing in many ways since there are less
security problems: virus writers have MORE problems than with the
android platform that is so open that viruses are present in many
applications in their store.

Anyway all I say here is my personal opinion of course, and I like
Apple, be warned.

jacob

 

[ec429]

hence Apples current poor performance...

I'm not sure if this is sarcasm or not, but on the off-chance that it
is, /me points at esr.ibiblio.org
And yes, I am a terrible ESR fanboi.
-e

 

[Ben Bacarisse]

Le 09/01/12 14:11, ec429 a écrit :

This closed environment is a god thing

Some typos just get to the heart of the matter in a way that no other
writing can.

 

[ArifulHossain tuhin]

Strictly follow POSIX and the C99 standard. Avoid using

compiler-specific extensions. Don't rely on the sizes of integer types;
if you need an N-bit int, use intN_t. If you need, for instance,
strndup, have some #ifdef-ed code that provides a replacement if it's
not present in the standard library. Hand-make a configure script that
tests for the things you need (by compiling and running tiny C programs)
and outputs that information into a file that gets included by your
Makefile (and defines some variable to hold some -D macro definitions
for the cpp). Hand-roll your makefile too, using implicit rules (%, $<
and $@ are your friends), but if some targets don't support GNU make,
you may need to write a tool to generate an explicit makefile from your
implicit rules (such a tool would be easier to write in, say, perl, than
in C).

I'm also a supporter of hand written makefiles too. I will try to do that with the project.

Making software portable to Symbian is difficult, a losing game, and
probably not worthwhile (Symbian will probably be dead soon anyway).
There exists "P.I.P.S Is Posix on Symbian" which may help, but according
to Wiki it lacks signals and asynch IO.
A reference implementation of RFCs probably does not need to be portable
to Symbian in any case; my suggestion would be that a Symbian
implementation should be a separate project. It is (so I gather) so
different to POSIX-like systems that the gyrations needed to make the
same code run on both platforms would impede the readability of the code
(which is important for reference imps).

Symbian portability is still a second thought. There is a huge user base ofsymbian devices in asian countries, So management is trying to push it down our throats.

On the more general note of avoiding Autotools, I would note that all my
open-source projects (there are several) use hand-written Makefiles,
none has a configure script, and I have yet to encounter anything more
severe than a few #ifdef WINDOWS to handle cross-compilation to that
platform (and separate make rules for Windows targets). With a
cross-compiling gcc, even Cygwin is not necessary (although it would be
if you wanted to /compile/ on Windows).

Thats what i'm looking for. Is it possible to give links of the projects you have worked on. I'm trying to learn the art of writing makefiles myself. Most of the opensource projects i have come across uses autotools. So some example of hand written makefiles will be very handy.

-e

Thanks for the heads up.

 

[Eric Sosman]

Why do you hate autotools? To me, any suggestion to avoid a tool in such
absolutist terms is unreasonable.

When I was very young, my parents gave me a bicycle. It had
what are known as "training wheels:" a pair of small wheels mounted
outrigger-style on the rear axle, positioned to ride about a foot
from the bicycle's center and an inch or so off the ground, ready
to arrest a sideways tilt caused by the novice rider's uncertain
balance.

I simply could *not* ride the damn thing. Kept trying to get it
to roll on the main wheel and on one or the other of the outriggers,
and it just wouldn't work. I'd been delighted with my shiny red
bicycle, but the delight quickly turned to tearful frustration.

Then my father took the training wheels off, and I jumped on
the bike and pedaled around shrieking with glee and happy as a
young clam.

Autoconf is sort of like that.

 

[ArifulHossain tuhin]

Why do you hate autotools? To me, any suggestion to avoid a tool in such
absolutist terms is unreasonable.


Rui Maciel

Because of the battles i had with configure scripts. Sometimes it just feels it can be done rather easily by hand tuned makefiles.

One example, there was a small project i was involved, which was modifying a tiny "media realy" software. The project has only 20 10-15 c files. we need to add some of our own. because of the hideous build systems. And it wasnot necessary to maintain this small project with autotools. we ended up writing custom makefiles for the project.

 

[ec429]

Anyway all I say here is my personal opinion of course, and I like
Apple, be warned.

Here's my personal opinion, and I don't like Apple, be warned
Any platform that you have to "develop for" is antithetical to
portability. The sheer diversity of the Unix ecosystem means that most
software in the Unix tradition is not developed for a given target
machine, rather it is developed as an abstract piece of software. This
not only aids portability to reasonably Unix-shaped systems (OS X,
NT...) but also encourages several other good practices (like
modularity, expressivity, and discoverability).

This closed environment is a god thing in many ways since there are less
security problems: virus writers have MORE problems than with the
android platform that is so open that viruses are present in many
applications in their store.

Contrariwise, Android apps are more likely to be open source (since it's
feasible to develop for Android without intending to make money out of
the software) meaning that the security-conscious end-user can compile
themselves, precluding the possibility of viruses (the end-user also
does not need an expensive Mac and SDK to do such compilation themselves).
It is also worth noting that viruses are no longer the chief vector of
malware; nowadays the real threats are trojans, network-side attacks,
and (overwhelmingly) social engineering. Those security holes which can
be defended against by software (as opposed to making clueless lusers
less moronic) are best handled by open source.
'Twas ever so, and so proceed.
-e

 

[ArifulHossain tuhin]

Le 09/01/12 11:26, ArifulHossain tuhin a écrit :

The range it should support is, from intel stuffs to arm processors(in
Iphone, ...


Look I develop for iPhone. Forget about any kind of makefile that you
have since:

1) An iphone Application can only be developed using the XCode IDE of
Apple.

I do not have a great deal of experience developing in Iphone platform. Butwith my limited understanding, i remember adding "Openssl development library" with an Iphone application once. Which went smoothly with the standard makefiles with some tweaks.

 

[ArifulHossain tuhin]

I'm not sure if this is sarcasm or not, but on the off-chance that it
is, /me points at esr.ibiblio.org
And yes, I am a terrible ESR fanboi.

I like him a lot. But i feel sometimes he goes kind of "overboard".

 

[ArifulHossain tuhin]

If you have no interaction with the iphone UI, you do not need Objective
C, and you can compile from the command line using
a normal makefile. The problem is that you will need to debug
your code and THAT needs XCode and the iphone connection.

I have ported and worked in a QT port to the iphone, and I
worked exclusively with the make environment of QT and their
source code using the command line in my Mac.

Since I was producing a library, I just included the library
into the user interface of my app. The library could be
debugged using the XCode debugger (that is actually just
a hacked version of gdb by Apple).

I have seen a similar task from a guy i know. He built a iphone app out of a standard library by just adding a front end. It should work.

Having a Mac is not that of a big deal: a "mini" mac starts at around
600 euros in the apple store, not a big deal. And, I am very happy with
it:

I have come to the best Unix that I know of: nice, good looking,
easy to use, everything works, powerful, etc It is a
nice change after all those years under windows.

This closed environment is a god thing in many ways since there are less
security problems: virus writers have MORE problems than with the
android platform that is so open that viruses are present in many
applications in their store.

Anyway all I say here is my personal opinion of course, and I like
Apple, be warned.

jacob

I disagree with the "security" concerns regarding open source. Open source codes get reviewed and audited(Think of the "Puffy", OpenBSD, the most secure OS is infact open source).
Mainstream Closed system often sacrifices security/safety stuffs in favor of "user friendliness".

 

[ArifulHossain tuhin]

Some typos just get to the heart of the matter in a way that no other
writing can.

I scared a intern in my office by laughing so loudly. Very "witty" stuff dude.

 

[ec429]

Thats what i'm looking for. Is it possible to give links of the projects you have worked on.

Most are listed on my website -Also see http://github.com/ec429
The biggest portability struggle I've had so far was with cwTBK, which
was not easy to port to Windows (largely because Windows has no
equivalent of ALSA's "arecord", nor a real command shell or terminal).

Most of what I know about project-architectural style, including how to
do Make right, I learned from ESR's brilliant "The Art of Unix
Programming" (http://catb.org/~esr/writings/taoup/). It's highly
recommended.

Read /Recursive Make Considered Harmful/, and absorb it (I've only used
recursive make for one project, 'horde', and then only to build modules
that never depend on each other, only on the top-level libhorde).

-e