Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #15611 > unrolled thread

Writing "absolutely" portable code

Back to article view | Back to comp.lang.c

Contents

  Writing "absolutely" portable code ArifulHossain tuhin <etothepowerpi@gmail.com> - 2012-01-09 02:26 -0800
    Re: Writing "absolutely" portable code ec429 <ec429@cam.ac.uk> - 2012-01-09 11:47 +0000
      Re: Writing "absolutely" portable code Jens Gustedt <jens.gustedt@loria.fr> - 2012-01-09 13:56 +0100
      Re: Writing "absolutely" portable code ArifulHossain tuhin <etothepowerpi@gmail.com> - 2012-01-09 05:45 -0800
        Re: Writing "absolutely" portable code ec429 <ec429@cam.ac.uk> - 2012-01-09 14:46 +0000
          Re: Writing "absolutely" portable code ArifulHossain tuhin <etothepowerpi@gmail.com> - 2012-01-10 01:11 -0800
      Re: Writing "absolutely" portable code Rui Maciel <rui.maciel@gmail.com> - 2012-01-09 15:58 +0000
      Re: Writing "absolutely" portable code falk@rahul.net (Edward A. Falk) - 2012-01-09 18:41 +0000
    Re: Writing "absolutely" portable code Rui Maciel <rui.maciel@gmail.com> - 2012-01-09 12:23 +0000
      Re: Writing "absolutely" portable code Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-01-09 08:45 -0500
        Re: Writing "absolutely" portable code superpollo <superpollo@tznvy.pbz> - 2012-01-09 15:02 +0100
          Re: Writing "absolutely" portable code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-09 16:11 +0000
      Re: Writing "absolutely" portable code ArifulHossain tuhin <etothepowerpi@gmail.com> - 2012-01-09 05:56 -0800
        Re: Writing "absolutely" portable code Rui Maciel <rui.maciel@gmail.com> - 2012-01-09 15:07 +0000
          Re: Writing "absolutely" portable code ArifulHossain tuhin <etothepowerpi@gmail.com> - 2012-01-10 01:21 -0800
            Re: Writing "absolutely" portable code Stephen Sprunk <stephen@sprunk.org> - 2012-01-10 13:20 -0600
              Re: Writing "absolutely" portable code ArifulHossain tuhin <etothepowerpi@gmail.com> - 2012-01-11 06:57 -0800
            Re: Writing "absolutely" portable code Rui Maciel <rui.maciel@gmail.com> - 2012-01-11 09:23 +0000
    Re: Writing "absolutely" portable code jacob navia <jacob@spamsink.net> - 2012-01-09 13:48 +0100
      Re: Writing "absolutely" portable code ec429 <ec429@cam.ac.uk> - 2012-01-09 13:11 +0000
        Re: Writing "absolutely" portable code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-01-09 05:27 -0800
          Re: Writing "absolutely" portable code ec429 <ec429@cam.ac.uk> - 2012-01-09 13:41 +0000
            Re: Writing "absolutely" portable code ArifulHossain tuhin <etothepowerpi@gmail.com> - 2012-01-09 06:09 -0800
        Re: Writing "absolutely" portable code jacob navia <jacob@spamsink.net> - 2012-01-09 14:35 +0100
          Re: Writing "absolutely" portable code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-01-09 13:44 +0000
            Re: Writing "absolutely" portable code ArifulHossain tuhin <etothepowerpi@gmail.com> - 2012-01-09 06:18 -0800
            Re: Writing "absolutely" portable code jacob navia <jacob@spamsink.net> - 2012-01-09 18:59 +0100
            Re: Writing "absolutely" portable code jacob navia <jacob@spamsink.net> - 2012-01-09 19:01 +0100
              Re: Writing "absolutely" portable code ec429 <ec429@cam.ac.uk> - 2012-01-09 19:21 +0000
                Re: Writing "absolutely" portable code Richard <rgrdev_@gmail.com> - 2012-01-10 20:48 +0100
                  Re: Writing "absolutely" portable code David Dyer-Bennet <dd-b@dd-b.net> - 2012-01-10 14:26 -0600
                    Re: Writing "absolutely" portable code Richard <rgrdev_@gmail.com> - 2012-01-10 21:44 +0100
                      Re: Writing "absolutely" portable code David Dyer-Bennet <dd-b@dd-b.net> - 2012-01-10 15:45 -0600
                  Re: Writing "absolutely" portable code Rui Maciel <rui.maciel@gmail.com> - 2012-01-11 09:12 +0000
                  Re: Writing "absolutely" portable code ec429 <ec429@cam.ac.uk> - 2012-01-11 11:10 +0000
                    Re: Writing "absolutely" portable code James Kuyper <jameskuyper@verizon.net> - 2012-01-11 11:52 -0500
                      Re: Writing "absolutely" portable code ec429 <ec429@cam.ac.uk> - 2012-01-11 17:01 +0000
                        Re: Writing "absolutely" portable code James Kuyper <jameskuyper@verizon.net> - 2012-01-11 12:11 -0500
                Re: Writing "absolutely" portable code Rui Maciel <rui.maciel@gmail.com> - 2012-01-11 09:08 +0000
              Re: Writing "absolutely" portable code Rui Maciel <rui.maciel@gmail.com> - 2012-01-11 08:22 +0000
              Re: Writing "absolutely" portable code Rui Maciel <rui.maciel@gmail.com> - 2012-01-11 08:54 +0000
          Re: Writing "absolutely" portable code ec429 <ec429@cam.ac.uk> - 2012-01-09 13:57 +0000
            Re: Writing "absolutely" portable code Seebs <usenet-nospam@seebs.net> - 2012-01-09 19:21 +0000
              Re: Writing "absolutely" portable code ec429 <ec429@cam.ac.uk> - 2012-01-09 19:52 +0000
                Re: Writing "absolutely" portable code Seebs <usenet-nospam@seebs.net> - 2012-01-09 20:20 +0000
          Re: Writing "absolutely" portable code ArifulHossain tuhin <etothepowerpi@gmail.com> - 2012-01-09 06:16 -0800
      Re: Writing "absolutely" portable code ArifulHossain tuhin <etothepowerpi@gmail.com> - 2012-01-09 06:02 -0800
    Re: Writing "absolutely" portable code Keith Thompson <kst-u@mib.org> - 2012-01-09 14:50 -0800
      Re: Writing "absolutely" portable code Kaz Kylheku <kaz@kylheku.com> - 2012-01-09 23:20 +0000
        Re: Writing "absolutely" portable code Rui Maciel <rui.maciel@gmail.com> - 2012-01-10 00:23 +0000
      Re: Writing "absolutely" portable code Dirk Zabel <zabel@riccius-sohn.eu> - 2012-01-10 17:44 +0100
        Re: Writing "absolutely" portable code ArifulHossain tuhin <etothepowerpi@gmail.com> - 2012-01-11 07:13 -0800
        Re: Writing "absolutely" portable code Nick Bowler <nbowler@draconx.ca> - 2012-01-17 20:36 +0000
          Re: Writing "absolutely" portable code ec429 <ec429@cam.ac.uk> - 2012-01-17 23:06 +0000
            Re: Writing "absolutely" portable code blp@cs.stanford.edu (Ben Pfaff) - 2012-01-17 15:32 -0800
              Re: Writing "absolutely" portable code Kaz Kylheku <kaz@kylheku.com> - 2012-01-18 00:40 +0000
                Re: Writing "absolutely" portable code Seebs <usenet-nospam@seebs.net> - 2012-01-18 18:35 +0000
                  Re: Writing "absolutely" portable code Kaz Kylheku <kaz@kylheku.com> - 2012-01-18 19:15 +0000
                    Re: Writing "absolutely" portable code Seebs <usenet-nospam@seebs.net> - 2012-01-21 21:32 +0000
              Re: Writing "absolutely" portable code "io_x" <a@b.c.invalid> - 2012-01-18 07:26 +0100
                Re: Writing "absolutely" portable code "Joachim Schmitz" <nospam.jojo@schmitz-digital.de> - 2012-01-18 11:07 +0100
                  Re: Writing "absolutely" portable code Seebs <usenet-nospam@seebs.net> - 2012-01-21 21:32 +0000
                    Re: Writing "absolutely" portable code Ian Collins <ian-news@hotmail.com> - 2012-01-22 10:42 +1300
                    Re: Writing "absolutely" portable code "io_x" <a@b.c.invalid> - 2012-01-22 18:53 +0100
                      Re: Writing "absolutely" portable code "io_x" <a@b.c.invalid> - 2012-01-22 19:00 +0100
                        Re: Writing "absolutely" portable code "io_x" <a@b.c.invalid> - 2012-01-23 19:28 +0100
                Re: Writing "absolutely" portable code Stephen Sprunk <stephen@sprunk.org> - 2012-01-18 08:44 -0600
                Re: Writing "absolutely" portable code James Dow Allen <jdallen2000@yahoo.com> - 2012-01-18 07:09 -0800
                  Re: Writing "absolutely" portable code "io_x" <a@b.c.invalid> - 2012-01-18 17:44 +0100
          Re: Writing "absolutely" portable code Seebs <usenet-nospam@seebs.net> - 2012-01-18 07:58 +0000

Page 1 of 4  [1] 2 3 4  Next page →

#15611 — Writing "absolutely" portable code

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 

[toc] | [next] | [standalone]

#15615

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

[toc] | [prev] | [next] | [standalone]

#15618

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

[toc] | [prev] | [next] | [standalone]

#15625

> 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 of symbian 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. 

[toc] | [prev] | [next] | [standalone]

#15639

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

[toc] | [prev] | [next] | [standalone]

#15682

On Monday, January 9, 2012 8:46:05 PM UTC+6, ec429 wrote:
> 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

Thanks for the links. That's very helpful.

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

I have skimmed over it in the past. Never took time to read it thoroughly. Thank you for the suggestion. I should read it through. I like the "Rob Pike's
"Unix Programming Environment". But its a bit outdated though. But the principle's are the same i guess.
 
> 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

[toc] | [prev] | [next] | [standalone]

#15643

ec429 wrote:

<snip/>
> Don't rely on the sizes of integer types;
> if you need an N-bit int, use intN_t.  

I would go a bit further than that.  It would be a good idea to define type 
names for primitive data types in a separate header (config.h), either 
through macro definitions or typedefs, and then set/update that definition 
based on checks performed by the configuration script.  

The GNU build system (i.e., autotools) was developed basically with this in 
mind, through the use of a config.h.in file, and cmake also supports this as 
well.

<snip/>

> 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 don't believe this suggestion is very good. Any flexibility which might be 
gained by developing our own shell scripts may require a relevant amount of 
maintenance and research, once we need to support more than one platform.  
There were good reasons why smart people decided to invest their time 
developing automated build systems in order to avoid hand-making configure 
scripts.


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

Again, this is the same problem I've previously pointed out.  If someone 
intends to avoid automatic build systems when developing portable projects 
and instead they opt to rely on all sorts of custom hand-written scripts, 
they are digging themselves into a hole from which they may experience a lot 
of problems just to escape it.

Another aspect which is rarely taken into account by those who decide to 
rely on a set of hand-crafted scripts to automate their build process is 
that another advantage in relying on automated build systems is familiarity.  
There is a wealth of information and discussion groups dedicated to specific 
automated build systems, and a considerable number of developers already 
have experience in writing/managing them.  It is also terribly easy for any 
developer who intends to use one to simply read up on them and, in a matter 
of minutes, get them up and running.  Therefore, it wouldn't be a challenge 
for a clueless newbie to read up on a standard/popular build system and not 
have a problem implementing basic stuff, such as adding files to a project.

The same doesn't necessarily apply to hand-crafted scripts.  Once a project 
grows after some point, the project's hand-crafted scripts tend to become, 
at least to those who didn't developed them, a violent mix of arcane 
enchantments and textual noise, which is practically impossible to 
understand, let alone maintain and update.  As those scripts represent a 
one-off attempt at writing a build script, there won't be a lot of help 
available to those who intend to decipher them.  So, although a specific mix 
of "let's hand-craft everything" may serve well a specific developer in that 
very specific occasion, it may undermine the ability to contribute by anyone 
else.  And this is a problem.


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

Like any tool ever developed, there is a threshold that marks the start of 
its usefulness.  Or, better yet, the point where applying that tool makes 
sense.

Considering build automation tools, their usefulness only kicks in if they 
actually help manage the build process.  In some tiny, one-off projects, 
even writing a simple makefile ends up being too much work which brings 
little to no reward. 

So, just because some projects can be adequately managed by a set of hand-
crafted makefiles and shell scripts, it doesn't mean that build automation 
tools are bad and should be avoided.  They do have their purpose and they do 
help a lot.  You only need to understand where and when it makes sense to 
rely on them, and in what cases it makes more sense to rely on other means.


Rui Maciel

[toc] | [prev] | [next] | [standalone]

#15650

In article <jeek4h$695$1@dont-email.me>, ec429  <ec429@cam.ac.uk> wrote:
>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.

I got tired of managing the ifdefs, and realized that the very few
functions I needed them for, e.g. strndup(), basename(), etc. could
easily be written in a few lines of C.  So I wrote my own StrnDup() and
BaseName() functions and now I don't worry about the different variants.

I know it seems stupid to replicate code that is in (some versions of)
the C library, but it turned out to be less work than dealing with all
the conditional compilation issues.


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

Ditto.

-- 
	-Ed Falk, falk@despams.r.us.com
	http://thespamdiaries.blogspot.com/

[toc] | [prev] | [next] | [standalone]

#15616

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

[toc] | [prev] | [next] | [standalone]

#15626

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
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#15629

Eric Sosman ha scritto:
> 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.

like what? the bike or the wheels?

[toc] | [prev] | [next] | [standalone]

#15644

superpollo <superpollo@tznvy.pbz> writes:

> Eric Sosman ha scritto:
<snip>
>>     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.
>
> like what? the bike or the wheels?

How could it be like the bike?  What would play the role of the training
wheels?  What is it that is holding autoconf back and which needs to be
removed for it to achieve it's full potential?

In my book, analogies are good when you are trying to explain something
complex (the universe is like a soap bubble...) but not very useful when
they are employed to say something simple (you'll be better off without
autoconf holding you back).

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#15628

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 was not necessary to maintain this small project with autotools. we ended up writing custom makefiles for the project.

[toc] | [prev] | [next] | [standalone]

#15642

ArifulHossain tuhin wrote:

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

Yes, tiny projects which don't require extensive configuration checks tend 
to be easier to maintain by writing a makefile and even test scripts 
ourselves.

Nonetheless, a build process only requires an automated build process if its 
size makes it impractical to manage custom makefiles and scripts by hand.


> 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
> was not necessary to maintain this small project with autotools. we ended
> up writing custom makefiles for the project.

That is strange.  Were those files C source code files?  And did anyone in 
that team had any experience with the GNU build system, or was everyone 
cutting their teeth on it?


Rui Maciel

[toc] | [prev] | [next] | [standalone]

#15683

On Monday, January 9, 2012 9:07:23 PM UTC+6, Rui Maciel wrote:
> ArifulHossain tuhin wrote:
> 
> > Because of the battles i had with configure scripts. Sometimes it just
> > feels it can be done rather easily by hand tuned makefiles.
> 
> Yes, tiny projects which don't require extensive configuration checks tend 
> to be easier to maintain by writing a makefile and even test scripts 
> ourselves.
> 
> Nonetheless, a build process only requires an automated build process if its 
> size makes it impractical to manage custom makefiles and scripts by hand.
> 
> 
> > 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
> > was not necessary to maintain this small project with autotools. we ended
> > up writing custom makefiles for the project.
> 
> That is strange.  Were those files C source code files?  And did anyone in 
> that team had any experience with the GNU build system, or was everyone 
> cutting their teeth on it?
> 
>

Our team was(and still is) little inexperienced dealing with Gnu Build system.
Lot of them used to develop in java/c# or visual studio. Our organization
is trying to train us, hopefully we won't be new in coming months. But still i believe a moderate sized project can be done by handwritten makefiles because the similarity in POSIX systems. Yes they require tweaks and won't be "automated". But autotools are no different. Most of the time, they need tweaks too. The problem is the "tweak"s are not very understandable because of the complexity associated with Autotools. Whereas makefiles are rather straight forward.
 
> Rui Maciel

[toc] | [prev] | [next] | [standalone]

#15696

On 10-Jan-12 03:21, ArifulHossain tuhin wrote:
> On Monday, January 9, 2012 9:07:23 PM UTC+6, Rui Maciel wrote:
>> ArifulHossain tuhin wrote:
>>> 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
>>> was not necessary to maintain this small project with autotools. we ended
>>> up writing custom makefiles for the project.
>>
>> That is strange.  Were those files C source code files?  And did anyone in 
>> that team had any experience with the GNU build system, or was everyone 
>> cutting their teeth on it?
> 
> Our team was(and still is) little inexperienced dealing with Gnu Build
> system.  Lot of them used to develop in java/c# or visual studio. Our
> organization is trying to train us, hopefully we won't be new in coming
> months.

Hopefully that training is coming from someone with significant
experience.  It can be a pretty steep learning curve.

> But still i believe a moderate sized project can be done by handwritten
> makefiles because the similarity in POSIX systems. Yes they require
> tweaks and won't be "automated".

That's the major feature of autotools: to not need to tweak makefiles
for each target platform.

For in-house apps that only have a few targets, learning autotools is
probably not worth the effort; for open-source apps that have to run on
dozens of targets, each with varying libraries and other apps installed,
and which may be cross-compiled or installed in different locations,
it's well worth it.

> But autotools are no different. Most of the time, they need tweaks too.

If so, you're (probably) doing it wrong.

> The problem is the "tweak"s are not very understandable because of the
> complexity associated with Autotools. Whereas makefiles are rather
> straight forward.

That's just a matter of what you're used to.  If I learned the autotools
system first, I'd probably find that easier than makefiles.  The build
systems in the MS tools are baffling to me, but if that's what you
learned first, that's probably easier for you than makefiles.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

[toc] | [prev] | [next] | [standalone]

#15752

On Wednesday, January 11, 2012 1:20:10 AM UTC+6, Stephen Sprunk wrote:
> On 10-Jan-12 03:21, ArifulHossain tuhin wrote:
> > On Monday, January 9, 2012 9:07:23 PM UTC+6, Rui Maciel wrote:
> >> ArifulHossain tuhin wrote:
> >>> 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
> >>> was not necessary to maintain this small project with autotools. we ended
> >>> up writing custom makefiles for the project.
> >>
> >> That is strange.  Were those files C source code files?  And did anyone in 
> >> that team had any experience with the GNU build system, or was everyone 
> >> cutting their teeth on it?
> > 
> > Our team was(and still is) little inexperienced dealing with Gnu Build
> > system.  Lot of them used to develop in java/c# or visual studio. Our
> > organization is trying to train us, hopefully we won't be new in coming
> > months.
> 
> Hopefully that training is coming from someone with significant
> experience.  It can be a pretty steep learning curve.
>

Training is not coming from a expert. In our country we do not have a lot guys working on linux/unix programming these days. Most of Linux/Unix guyz we have are admins. They know little about build systems in depth.
 
> > But still i believe a moderate sized project can be done by handwritten
> > makefiles because the similarity in POSIX systems. Yes they require
> > tweaks and won't be "automated".
> 
> That's the major feature of autotools: to not need to tweak makefiles
> for each target platform.
> 
> For in-house apps that only have a few targets, learning autotools is
> probably not worth the effort; for open-source apps that have to run on
> dozens of targets, each with varying libraries and other apps installed,
> and which may be cross-compiled or installed in different locations,
> it's well worth it.
> 

Its going to be deployed on customer's infrastructures.


> > But autotools are no different. Most of the time, they need tweaks too.
> 
> If so, you're (probably) doing it wrong.
>

Maybe, because i do not have a lot of experience regarding autotools. I'm also a admin turned developer. my bad :)

 
> > The problem is the "tweak"s are not very understandable because of the
> > complexity associated with Autotools. Whereas makefiles are rather
> > straight forward.
> 
> That's just a matter of what you're used to.  If I learned the autotools
> system first, I'd probably find that easier than makefiles.  The build
> systems in the MS tools are baffling to me, but if that's what you
> learned first, that's probably easier for you than makefiles.
> 
> S
> 
> -- 
> Stephen Sprunk         "God does not play dice."  --Albert Einstein
> CCIE #3723         "God is an inveterate gambler, and He throws the
> K5SSS        dice at every possible opportunity." --Stephen Hawking

[toc] | [prev] | [next] | [standalone]

#15738

ArifulHossain tuhin wrote:

> Our team was(and still is) little inexperienced dealing with Gnu Build
> system. Lot of them used to develop in java/c# or visual studio. Our
> organization is trying to train us, hopefully we won't be new in coming
> months. But still i believe a moderate sized project can be done by
> handwritten makefiles because the similarity in POSIX systems. Yes they
> require tweaks and won't be "automated". But autotools are no different.
> Most of the time, they need tweaks too. The problem is the "tweak"s are
> not very understandable because of the complexity associated with
> Autotools. Whereas makefiles are rather straight forward.

In my opinion, the main flaw which affects the GNU Build System is its sub-
par documentation, which needlessly contributes to its steep learning curve.  
Maybe it's even responsible for it.  Nonetheless, once someone gets the hang 
of it, things tend to work well.  It's just a matter of reading the right 
documentation and checking how others have set up their own projects.


Rui Maciel

[toc] | [prev] | [next] | [standalone]

#15617

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!
:-)

[toc] | [prev] | [next] | [standalone]

#15620

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

[toc] | [prev] | [next] | [standalone]

Page 1 of 4  [1] 2 3 4  Next page →

Back to top | Article view | comp.lang.c

csiph-web