Writing "absolutely" portable code

Discussion in 'C Programming' started by ArifulHossain tuhin, Jan 9, 2012.

  1. 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
    ArifulHossain tuhin, Jan 9, 2012
    #1
    1. Advertising

  2. ArifulHossain tuhin

    ec429 Guest

    On 09/01/12 10:26, ArifulHossain tuhin wrote:
    > 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
    --
    'sane', adj.: see 'unimaginative'
    on the web - http://jttlov.no-ip.org
    ec429, Jan 9, 2012
    #2
    1. Advertising

  3. ArifulHossain tuhin

    Rui Maciel Guest

    ArifulHossain tuhin wrote:

    > 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
    Rui Maciel, Jan 9, 2012
    #3
  4. ArifulHossain tuhin

    jacob navia Guest

    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!
    :)
    jacob navia, Jan 9, 2012
    #4
  5. ArifulHossain tuhin

    Jens Gustedt Guest

    Am 01/09/2012 12:47 PM, schrieb ec429:
    > On 09/01/12 10:26, ArifulHossain tuhin wrote:
    >> 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).


    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
    Jens Gustedt, Jan 9, 2012
    #5
  6. ArifulHossain tuhin

    Stefan Ram Guest

    jacob navia <> writes:
    >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.
    Stefan Ram, Jan 9, 2012
    #6
  7. ArifulHossain tuhin

    ec429 Guest

    On 09/01/12 13:01, Stefan Ram wrote:
    > 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
    --
    'sane', adj.: see 'unimaginative'
    on the web - http://jttlov.no-ip.org
    ec429, Jan 9, 2012
    #7
  8. On Jan 9, 1:11 pm, ec429 <> wrote:

    > 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...
    Nick Keighley, Jan 9, 2012
    #8
  9. ArifulHossain tuhin

    jacob navia Guest

    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
    jacob navia, Jan 9, 2012
    #9
  10. ArifulHossain tuhin

    ec429 Guest

    On 09/01/12 13:27, Nick Keighley wrote:
    > On Jan 9, 1:11 pm, ec429<> wrote:
    >
    >> 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...

    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
    --
    'sane', adj.: see 'unimaginative'
    on the web - http://jttlov.no-ip.org
    ec429, Jan 9, 2012
    #10
  11. jacob navia <> writes:

    > Le 09/01/12 14:11, ec429 a écrit :
    >> Then again, if iPhone is as painfully locked down as jacob suggests, it
    >> might be better to just not support it

    <snip>
    > 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.

    --
    Ben.
    Ben Bacarisse, Jan 9, 2012
    #11
  12. > 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
    > --
    > 'sane', adj.: see 'unimaginative'
    > on the web - http://jttlov.no-ip.org

    Thanks for the heads up.
    ArifulHossain tuhin, Jan 9, 2012
    #12
  13. ArifulHossain tuhin

    Eric Sosman Guest

    On 1/9/2012 7:23 AM, Rui Maciel wrote:
    > ArifulHossain tuhin wrote:
    >
    >> 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.


    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.

    --
    Eric Sosman
    d
    Eric Sosman, Jan 9, 2012
    #13
  14. On Monday, January 9, 2012 6:23:40 PM UTC+6, Rui Maciel wrote:
    > ArifulHossain tuhin wrote:
    >
    > > 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


    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.
    ArifulHossain tuhin, Jan 9, 2012
    #14
  15. ArifulHossain tuhin

    ec429 Guest

    On 09/01/12 13:35, jacob navia wrote:
    > 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
    --
    'sane', adj.: see 'unimaginative'
    on the web - http://jttlov.no-ip.org
    ec429, Jan 9, 2012
    #15
  16. On Monday, January 9, 2012 6:48:21 PM UTC+6, jacob navia wrote:
    > 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.
    >

    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.
    > 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!
    > :)
    ArifulHossain tuhin, Jan 9, 2012
    #16
  17. On Monday, January 9, 2012 7:41:39 PM UTC+6, ec429 wrote:
    > On 09/01/12 13:27, Nick Keighley wrote:
    > > On Jan 9, 1:11 pm, ec429<> wrote:
    > >
    > >> 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...

    > 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".
    > -e
    > --
    > 'sane', adj.: see 'unimaginative'
    > on the web - http://jttlov.no-ip.org
    ArifulHossain tuhin, Jan 9, 2012
    #17

  18. > 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, Jan 9, 2012
    #18
  19. On Monday, January 9, 2012 7:44:21 PM UTC+6, Ben Bacarisse wrote:
    > jacob navia <> writes:
    >
    > > Le 09/01/12 14:11, ec429 a écrit :
    > >> Then again, if iPhone is as painfully locked down as jacob suggests, it
    > >> might be better to just not support it

    > <snip>
    > > 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.


    I scared a intern in my office by laughing so loudly. Very "witty" stuff dude.
    >
    > --
    > Ben.
    ArifulHossain tuhin, Jan 9, 2012
    #19
  20. ArifulHossain tuhin

    ec429 Guest

    On 09/01/12 13:45, ArifulHossain tuhin wrote:
    > 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 -
    >> on the web - http://jttlov.no-ip.org

    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
    --
    'sane', adj.: see 'unimaginative'
    on the web - http://jttlov.no-ip.org
    ec429, Jan 9, 2012
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Eli Bendersky
    Replies:
    1
    Views:
    1,152
    Mike Treseler
    Mar 1, 2006
  2. John A Grandy
    Replies:
    3
    Views:
    324
    darrel
    Jun 15, 2004
  3. Replies:
    7
    Views:
    901
  4. Richard Giuly
    Replies:
    5
    Views:
    2,725
    Noah Roberts
    Jul 31, 2006
  5. jacob navia

    Writing portable code...

    jacob navia, Sep 2, 2007, in forum: C Programming
    Replies:
    7
    Views:
    294
    Kelsey Bjarnason
    Sep 3, 2007
Loading...

Share This Page