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 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#15732

jacob navia wrote:

> Linux people are very conservative, and their version of Unix is frozen
> around 1980. Apple did a better Unix. And I am not speaking about the
> wonderful and intuitive user interface, the great LOOKS, the package
> management system that has hundreths of public domain applications
> ported to Apple Unix, etc etc.

I don't know what you mean by "Linux people".  As you know, linux itself is 
only an OS kernel.  From there, there is a considerable number of people and 
organizations who, independently, put together operating systems which are 
based on the linux kernel.  Some of those projects don't even rely 
exclusively on the linux kernel, as they also provide essentially the same 
operating system with kernels other than the linux one.  

Anyway, there isn't a concerted effort dictated by a centralized authority 
intended to steer the technical direction of those projects.  Well, at least 
beyond the scope of each individual project.

Therefore, until a meaningful definition for "linux people" is provided, 
your assertion is meaningless.  And even if one is provided, I seriously 
doubt your initial assertion will hold.


> I am really satisfied with my Mac, sorry. It is EXACTLY what linux
> could have been if they would have worked in making a BETTER Unix
> instead of producing several dozens of different window management
> systems (equally bad and equally awful) and several dozens of equally
> bad IDEs.

This assertion is absurd.  There is no centralized authority wasting 
resources on redundant projects.  There are multiple, independent people 
investing their time developing a set of projects independently.  
Criticizing someone for, in his spare time, having put together a window 
manager isn't a reasonable thing to do, particularly if the only complain 
which is being made is that there are already competing projects out there.  
For example, the same criticism that you are directing at the "several dozen 
different window management systems" can also be used to complain about 
jacob navia's compiler.  Do you also believe that you should have worked in 
making a better anything instead of producing one of the several dozen 
different compilers already available, each equally bad and equally awful?


> They never think about the USER EXPERIENCE when designing their programs
> (just look at gdb), something Apple has always had in mind.

What's wrong with gdb?


Rui Maciel

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

#15627

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

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

#15654

On 2012-01-09, ec429 <ec429@cam.ac.uk> wrote:
> 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).

What are you talking about?

The SDK is free last I checked; it's certainly not very expensive, and I
seem to recall that there's a Windows port.  I don't know.  A cheap mac is
cheap and perfectly adequate for iOS development.

I've developed an iOS app and will likely develop more; I doubt it'll be
profitable, but I have fun working on it because the iOS API is a lot more
pleasant for me to use than any of the GUI options offered by the *nix side
of the world.

I would rather have a more open system, but a system designed coherently is
enough better than systems thrown together by people who didn't understand
the problem space that I'll put up with it.

You probably know the old saying, "you have to understand the rules before
you can break them."  Android consists of people who did not understand why
iOS was the way it was systematically breaking all of its rules out of spite.

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

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

#15656

On 09/01/12 19:21, Seebs wrote:
> You probably know the old saying, "you have to understand the rules before
> you can break them."  Android consists of people who did not understand why
> iOS was the way it was systematically breaking all of its rules out of spite.
I could just as easily say that Apple consists of people who did not 
understand why Unix was the way it was, systematically breaking all of 
/its/ rules out of spite.
However, I do not attribute to spite that which can be adequately 
explained by incompetence.
Unix' design /is/ coherent; it may have a few crocky warts for 
hysterical raisins, but it has central, unifying principles - moreover, 
it has the /right/ central unifying principles.
My thesis that iOS will wither and die, and Android will subsume, while 
partly based on market data from ComScore via esr, is also significantly 
based on the observed success of the design philosophy that has been 
dubbed "Worse Is Better".
Those who do not learn from Unix are doomed to reinvent it, poorly.

A cheap Mac may be cheap.  But I can develop for Windows on a Linux box, 
or develop for Linux on a Windows box.  If you ask me to buy your 
hardware in order to develop for it, I ask you to stop wasting my time 
and bug someone else.

I stand corrected on the SDK though; maybe I'm thinking of the App Store 
costs, and ISTR that those are waived for free apps.  But I don't know 
the details.

Nonetheless, the impression I get is that the iOS ecosystem is not 
conducive to the practices of open source and casual hacking which I 
consider central to a strong software engineering tradition.

-e
-- 
'sane', adj.: see 'unimaginative'
   on the web - http://jttlov.no-ip.org

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

#15657

On 2012-01-09, ec429 <ec429@cam.ac.uk> wrote:
> I could just as easily say that Apple consists of people who did not 
> understand why Unix was the way it was, systematically breaking all of 
> /its/ rules out of spite.

You could, except that OS X *is* Unix.  So's iOS, under the hood.

> I stand corrected on the SDK though; maybe I'm thinking of the App Store 
> costs, and ISTR that those are waived for free apps.  But I don't know 
> the details.

It's cheap enough that I did it just so I could run an app I wanted to
write on my own phone, and I don't remember what it cost.

> Nonetheless, the impression I get is that the iOS ecosystem is not 
> conducive to the practices of open source and casual hacking which I 
> consider central to a strong software engineering tradition.

I'd somewhat agree, but the huge overlap with OS X development (which is
free and has no particular requirements) leaves us with a pretty healthy
community.

And it is a LOT more pleasant to work with, IME.

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

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

#15632

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

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

#15630

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. But with 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!
> :-)

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

#15665

ArifulHossain tuhin <etothepowerpi@gmail.com> writes:
> 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.
[...]
> 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.
[...]

One advantage of GNU autotools, from the perspective of a user
installing software from source, is that they impose a consistent set of
commands to build and install packages.  A typical sequence is:

    tar zxf foobar-0.1.tar.gz
    cd foobar-0.1
    ./configure --prefix=/some/where/foo-0.1
    make
    make install

Packages with custom configuration, building, and installation scripts
often impose a substantial burden if they don't follow a conventional
sequence of commands.  If they do, that's great, but I'd really rather
not have to manually edit some file (whose identify is documented in
README, or INSTALL, or is it installation-instructions.txt?) if I want
to install it in a non-default location.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#15669

On 2012-01-09, Keith Thompson <kst-u@mib.org> wrote:
> ArifulHossain tuhin <etothepowerpi@gmail.com> writes:
>> 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.
> [...]
>> 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.
> [...]
>
> One advantage of GNU autotools, from the perspective of a user
> installing software from source, is that they impose a consistent set of
> commands to build and install packages.

This is not an advantage of autotools, because anyone can write a script called
"configure" by hand which imitates the conventions, and do a much
better job of it.

Furthermore programs that use autotools do not really have consistent
conventions beyond that there is a script called "configure".

>     tar zxf foobar-0.1.tar.gz
>     cd foobar-0.1
>     ./configure --prefix=/some/where/foo-0.1
>     make

--prefix is pretty ubiquitous, but it rapidly breaks down from there.

>     make install

So now, what is the convention to put the program somewhere
other than in /some/where/foo-0.1?

For some programs it is this:

  make DESTDIR=/package/dir install

(/package/dir gets combined with the --prefix so there will be
/package/dir/some/where/foo-0.1)

For some others, there is configure argument, like

  ./configure --prefix=/foo --install-dir=/package/dir

> Packages with custom configuration, building, and installation scripts
> often impose a substantial burden if they don't follow a conventional
> sequence of commands.  

Nothing imposes a greater burden than a program which can't be built
for architecture X without executing architecture X code at build time.

I think many Linux distro maintainers would happily have every program follow
its own conventions, if they all could be cross-built without having to create
stupid little environments where stuff runs under chroot (because it wants to
wrongly access build-machine paths,  not sticking to the sysroot) or even under
QEMU (because the build wants to run target architecture code, even when
cross-compiling).

Configure and build systems that work cleanly, do not pick up build machine
pollution, and cross-compile without emulation are more improtant than shitty,
broken build systems that are vaguely compatible with each other in the
syntactic trivialities like --path.

> If they do, that's great, but I'd really rather
> not have to manually edit some file (whose identify is documented in
> README, or INSTALL, or is it installation-instructions.txt?) if I want
> to install it in a non-default location.

If the program's build system doesn't suck, I will gladly RTFM inside it and
follow how it wants it done.

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

#15673

Kaz Kylheku wrote:

> On 2012-01-09, Keith Thompson <kst-u@mib.org> wrote:
>> One advantage of GNU autotools, from the perspective of a user
>> installing software from source, is that they impose a consistent set of
>> commands to build and install packages.
> 
> This is not an advantage of autotools, because anyone can write a script
> called "configure" by hand which imitates the conventions, and do a much
> better job of it.

But does everyone do that?  And how much of an hastle is it to maintain some 
convoluted build script which you didn't wrote it yourself and hasn't been 
written with maintenance in mind?  


> Furthermore programs that use autotools do not really have consistent
> conventions beyond that there is a script called "configure".

Could you please elaborate on that?


<snip/>

> So now, what is the convention to put the program somewhere
> other than in /some/where/foo-0.1?
>
> For some programs it is this:
> 
>   make DESTDIR=/package/dir install
>
> (/package/dir gets combined with the --prefix so there will be
> /package/dir/some/where/foo-0.1)
> 
> For some others, there is configure argument, like
> 
>   ./configure --prefix=/foo --install-dir=/package/dir

It really depends on what you define as being "the program".  The configure 
scripts generated by the GNU build system provide a set of options to 
configure a set of directories which come in handy in installing a software 
package.  For example, the --bindir option is used to specify the directory 
into which the user executables are copied, and there are options available 
to set other target directories used to install system admin executables, 
object code libraries, pdf documentation, etc...


>> Packages with custom configuration, building, and installation scripts
>> often impose a substantial burden if they don't follow a conventional
>> sequence of commands.
> 
> Nothing imposes a greater burden than a program which can't be built
> for architecture X without executing architecture X code at build time.

I don't see how that is a problem caused by the GNU build system, or any 
other automatic build system, for that matter.  In fact, it is quite 
possible to develop a hand-crafted build script which relies on some feature 
which isn't available in a system.


> I think many Linux distro maintainers would happily have every program
> follow its own conventions, if they all could be cross-built without
> having to create stupid little environments where stuff runs under chroot
> (because it wants to
> wrongly access build-machine paths,  not sticking to the sysroot) or even
> under QEMU (because the build wants to run target architecture code, even
> when cross-compiling).
> 
> Configure and build systems that work cleanly, do not pick up build
> machine pollution, and cross-compile without emulation are more improtant
> than shitty, broken build systems that are vaguely compatible with each
> other in the syntactic trivialities like --path.

Your complaint boils down to "a build script might be buggy".  Hand-crafted 
scripts aren't immune to bugs.  They are also vulnerable to poor design 
decisions and lack of insight from the developer. 



Rui Maciel

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

#15687

Am 09.01.2012 23:50, schrieb Keith Thompson:
> ArifulHossain tuhin<etothepowerpi@gmail.com>  writes:
>> 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.
> [...]
>> 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.
> [...]
>
> One advantage of GNU autotools, from the perspective of a user
> installing software from source, is that they impose a consistent set of
> commands to build and install packages.  A typical sequence is:
>
>      tar zxf foobar-0.1.tar.gz
>      cd foobar-0.1
>      ./configure --prefix=/some/where/foo-0.1
If it works, fine.
Unfortunately, this step very often does not work for me. I am regularly 
trying to cross-compile for an embedded, ppc-based linux system, which 
in theory should be possible with the configure-parameter

  --host=ppc-XXX-linux

Very often I have to work long until configure works. And if it works, 
there is no guarantee that the next step, i.e. "make" works. And if that 
works, there might be subtle errors which show up later when the program 
runs on the target platform. Sometimes I don't get configure to work 
anyway or decide, that it's not worth the time. For example, I once 
tried to build apache for my target platform without success. Finally, I 
decided to use another webserver (lighttpd), which might be more 
appropriate anyway, but I wanted to give apache a try.
Just now I am in the process to cross-compile php for my target. The 
first issue was that the target has MSB byte-order, which the configure 
script did not care about. The actual sources had #ifdefs to take 
byte-order into account, so after patching the byte-order information 
into configure, I could solve this. But I have yet to solve further 
problems. Often the configure-script tries to compile and run short 
test-programs in order to find something out. This of course always 
fails if you try to cross-compile. Than I have first to see what 
information the configure script tried to aquire and how I can provide 
this information manually. No, I don't like this.

So from this experiences, I would greatly prefer a manually written, 
clean makefile together with some pre-written config.h where the 
system-dependent definitions are visible. Btw I don't think, a manually 
written script configuration script would be better, I think it could be 
even worse.

Regards
   Dirk

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

#15754

On Tuesday, January 10, 2012 10:44:07 PM UTC+6, Dirk Zabel wrote:
> Unfortunately, this step very often does not work for me. I am regularly 
> trying to cross-compile for an embedded, ppc-based linux system, which 
> in theory should be possible with the configure-parameter
> 
>   --host=ppc-XXX-linux
> 
> Very often I have to work long until configure works. And if it works, 
> there is no guarantee that the next step, i.e. "make" works. And if that 
> works, there might be subtle errors which show up later when the program 
> runs on the target platform. Sometimes I don't get configure to work 
> anyway or decide, that it's not worth the time. For example, I once 
> tried to build apache for my target platform without success. Finally, I 
> decided to use another webserver (lighttpd), which might be more 
> appropriate anyway, but I wanted to give apache a try.
> Just now I am in the process to cross-compile php for my target. The 
> first issue was that the target has MSB byte-order, which the configure 
> script did not care about. The actual sources had #ifdefs to take 
> byte-order into account, so after patching the byte-order information 
> into configure, I could solve this. But I have yet to solve further 
> problems. Often the configure-script tries to compile and run short 
> test-programs in order to find something out. This of course always 
> fails if you try to cross-compile. Than I have first to see what 
> information the configure script tried to aquire and how I can provide 
> this information manually. No, I don't like this.
> 
> So from this experiences, I would greatly prefer a manually written, 
> clean makefile together with some pre-written config.h where the 
> system-dependent definitions are visible. Btw I don't think, a manually 
> written script configuration script would be better, I think it could be 
> even worse.
> 
> Regards
>    Dirk

Excellent explanation. That's exactly what happens to me, and i'm guessing many others. Sometimes it takes hours to fix the ./configure stage. In which time a custom makefile can be written if someone has some understanding.

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

#15891

On Tue, 10 Jan 2012 17:44:07 +0100, Dirk Zabel wrote:
> Am 09.01.2012 23:50, schrieb Keith Thompson:
>> One advantage of GNU autotools, from the perspective of a user
>> installing software from source, is that they impose a consistent set of
>> commands to build and install packages.  A typical sequence is:
>>
>>      tar zxf foobar-0.1.tar.gz
>>      cd foobar-0.1
>>      ./configure --prefix=/some/where/foo-0.1
> If it works, fine.
> Unfortunately, this step very often does not work for me. I am regularly 
> trying to cross-compile for an embedded, ppc-based linux system, which 
> in theory should be possible with the configure-parameter
> 
>   --host=ppc-XXX-linux
>
> Very often I have to work long until configure works.
[snip rant about various failures that occur during cross compilation].

All of this is the result of a single problem: the package developer(s)
did not test cross compilation, a feature which autoconf was explicitly
designed to support.  They did not try it even once.  Or if they did,
they did not bother to fix the problems that they doubtless encountered.

> So from this experiences, I would greatly prefer a manually written, 
> clean makefile together with some pre-written config.h where the 
> system-dependent definitions are visible.

I cannot fathom why anyone would expect a from-scratch build system
written by such developers to feature better support for cross
compilation.

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

#15894

On 17/01/12 20:36, Nick Bowler wrote:
> On Tue, 10 Jan 2012 17:44:07 +0100, Dirk Zabel wrote:
>> So from this experiences, I would greatly prefer a manually written,
>> clean makefile together with some pre-written config.h where the
>> system-dependent definitions are visible.
>
> I cannot fathom why anyone would expect a from-scratch build system
> written by such developers to feature better support for cross
> compilation.
Perhaps because a build system that doesn't try to autoguess the values 
of system-dependent things, doesn't break when the build machine and 
target machine are different?
If you're cross-compiling, and the package uses autoconf, how's it going 
to find out the values it normally gets by compiling and running test 
programs?
Autotools tries to be a generic tool, and doesn't make the best job of 
it.  A clean makefile and a config.h has the important advantage of 
being /minimal/; it doesn't know, nor seek to know, anything that it 
doesn't need - and it doesn't try to be clever, either.
-ə
-- 
'sane', adj.: see 'unimaginative'
   on the web - http://jttlov.no-ip.org

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

#15895

ec429 <ec429@cam.ac.uk> writes:

> On 17/01/12 20:36, Nick Bowler wrote:
>> On Tue, 10 Jan 2012 17:44:07 +0100, Dirk Zabel wrote:
>>> So from this experiences, I would greatly prefer a manually written,
>>> clean makefile together with some pre-written config.h where the
>>> system-dependent definitions are visible.
>>
>> I cannot fathom why anyone would expect a from-scratch build system
>> written by such developers to feature better support for cross
>> compilation.
> Perhaps because a build system that doesn't try to autoguess the
> values of system-dependent things, doesn't break when the build
> machine and target machine are different?
> If you're cross-compiling, and the package uses autoconf, how's it
> going to find out the values it normally gets by compiling and running
> test programs?

Autoconf doesn't normally try to run test programs.  Most of the
time, it only tries to compile and link them.  In the cases where
running is desirable, normally one makes the Autoconf tests take
a conservative guess at the result.
-- 
A competent C programmer knows how to write C programs correctly,
a C expert knows enough to argue with Dan Pop, and a C expert
expert knows not to bother.

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

#15897

On 2012-01-17, Ben Pfaff <blp@cs.stanford.edu> wrote:
> ec429 <ec429@cam.ac.uk> writes:
>
>> On 17/01/12 20:36, Nick Bowler wrote:
>>> On Tue, 10 Jan 2012 17:44:07 +0100, Dirk Zabel wrote:
>>>> So from this experiences, I would greatly prefer a manually written,
>>>> clean makefile together with some pre-written config.h where the
>>>> system-dependent definitions are visible.
>>>
>>> I cannot fathom why anyone would expect a from-scratch build system
>>> written by such developers to feature better support for cross
>>> compilation.
>> Perhaps because a build system that doesn't try to autoguess the
>> values of system-dependent things, doesn't break when the build
>> machine and target machine are different?
>> If you're cross-compiling, and the package uses autoconf, how's it
>> going to find out the values it normally gets by compiling and running
>> test programs?
>
> Autoconf doesn't normally try to run test programs.  Most of the
> time, it only tries to compile and link them.  In the cases where
> running is desirable, normally one makes the Autoconf tests take
> a conservative guess at the result.

The conservative guesses are often stupidly inappropriate.

A much better response would be to fail the configure with a big message
at the end like this:

  *** The program can't be configured because it is being cross-compiled,
  *** and so some of the tests which run test programs cannot be executed.
  *** Here are all the variables whose values you need to export to do
  *** the right thing (so you don't have to read the configure script):
  *** ac_cv_blah=yes   # this indicates the target has blah support
  *** ac_cv_blorch=yes # the target has blorch support

What happens instead is the program configures successfully anyway.  You have
to read the output of configure, spot the problems, gather them into a list,
and then dig through the configure script to find out what variables to
manipulate to get a proper build.

Another better response, rather than failing, would be to try to make better
use of available information.

For instance, suppose that the --target is specified as a tuple which encodes
not only the fact that we are compiling for MIPS or ARM, but also that the OS
is linux.  The config system has no excuse for not taking advantage of this
little fact that was given to it as input.  If you know that the OS is Linux,
then you know, for instance, that the target OS has POSIX job control, so you
don't have to bother testing for it, and you certainly don't need to assume
that it's not there.

Yet the job control test in GNU Bash's configure script defaults to "no"
if it is not able to run the configure test. Linux or not, it will build
a bash that has no Ctrl-Z, and no "jobs", "fg" or "bg".

A couple of years ago, Wind River was shipping a compiled bash with no job
control because of this issue.  When cross compiling bash, they just trusted
that configure did the job because it ran successfully and an executable popped
out make.

It's very hard to test for every single thing like this across an entire OS.
You never know where something is crippled because a cross-compiling test
was *silently* not run and a poor-quality default substituted in its place.

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

#15915

On 2012-01-18, Kaz Kylheku <kaz@kylheku.com> wrote:
> A couple of years ago, Wind River was shipping a compiled bash with no job
> control because of this issue.  When cross compiling bash, they just trusted
> that configure did the job because it ran successfully and an executable popped
> out make.

It's more subtle than that, apparently, and was most recently fixed in January
of 2007.  Looking at it, it appears that all the standard stuff in bash's
configure uses a value bash_cv_job_control_missing, which would normally be
set to either "present" or "missing".  We had a build file which was setting it
to "no", but was not setting it in the right way; it looks to me as though
the intent had been the logical equivalent of:
	bash_cv_job_control_missing=no configure <args>
but it ended up working as though it were:
	bash_cv_job_control_missing=no
	configure <args>

So it wasn't trusting configure, it wasn't being careful enough to verify that
the fix was still working; it had been originally fixed back in 2006, and then a
change in July of 2006 moved the fix to a new location as part of a version uprev,
and it stopped working -- this slipped through the cracks for about 5 months.

... this has basically nothing to do with C, but I was too curious not to look.

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

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

#15918

On 2012-01-18, Seebs <usenet-nospam@seebs.net> wrote:
> On 2012-01-18, Kaz Kylheku <kaz@kylheku.com> wrote:
>> A couple of years ago, Wind River was shipping a compiled bash with no job
>> control because of this issue.  When cross compiling bash, they just trusted
>> that configure did the job because it ran successfully and an executable popped
>> out make.
>
> It's more subtle than that, apparently, and was most recently fixed in January
> of 2007.  Looking at it, it appears that all the standard stuff in bash's
> configure uses a value bash_cv_job_control_missing, which would normally be
> set to either "present" or "missing".  We had a build file which was setting it
> to "no", but was not setting it in the right way; it looks to me as though
> the intent had been the logical equivalent of:
> 	bash_cv_job_control_missing=no configure <args>
> but it ended up working as though it were:
> 	bash_cv_job_control_missing=no
> 	configure <args>

Ah, let me guess, missing backslash? :)

Thanks for providing me the necessary emotional closure on this one, haha.

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

#16019

On 2012-01-18, Kaz Kylheku <kaz@kylheku.com> wrote:
> On 2012-01-18, Seebs <usenet-nospam@seebs.net> wrote:
>> It's more subtle than that, apparently, and was most recently fixed in January
>> of 2007.  Looking at it, it appears that all the standard stuff in bash's
>> configure uses a value bash_cv_job_control_missing, which would normally be
>> set to either "present" or "missing".  We had a build file which was setting it
>> to "no", but was not setting it in the right way; it looks to me as though
>> the intent had been the logical equivalent of:
>> 	bash_cv_job_control_missing=no configure <args>
>> but it ended up working as though it were:
>> 	bash_cv_job_control_missing=no
>> 	configure <args>

> Ah, let me guess, missing backslash? :)

Nothing so obvious!  In the original it was Makefile variables, then we moved
to an SRPM package, and the SRPM package had
	bash_cv_job_control_missing=no \
	%configure [...]

and apparently this doesn't work, but changing it to "export" does.  I don't
know the definition of %configure, but I'm guessing it was the underlying
mechanic.

... I know none of this is really relevant to C, but it *is* somewhat relevant
to the question of why cross-compilation can be hard, and why I hate autoconf.
Stuff like this requires you to ensure that certain values are stashed in
environment variables or cache files, and that can be a nightmare to maintain.

I think experience with portability stuff like this is a great thing for any C
programmer.  People who haven't had to deal with this are often quite quick to
carefully write multiple versions of something that each make unportable
assumptions; experience with this teaches the value of figuring out how to write
something that is portable in that it works everywhere, rather than in that it
works in three specific places.  :)

I occasionally see people making things "portable" by doing things like:

	#ifdef BIG_ENDIAN
		#ifdef INT_32_BITS
		if (((char *) x)[3] == 23) {
			/* ... */
		}
		#else
		if (((char *) x)[7] == 23) {
			/* ... */
		}
		#endif
	#else
		if (((char *) x)[0] == 23) {
			/* ... */
		}
	#endif

I would rather see:
	if ((x & 0xff) == 23) {
		/* ... */
	}

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

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

#15899

"Ben Pfaff" <blp@cs.stanford.edu> ha scritto nel messaggio
news:87haztzyze.fsf@blp.benpfaff.org...
> ec429 <ec429@cam.ac.uk> writes:

> A competent C programmer knows how to write C programs correctly,
> a C expert knows enough to argue with Dan Pop, and a C expert
> expert knows not to bother.

and where are the ones, the peoples claim nether
the expert expert can write a C programs correctly 100%?
[only assembly programmers could write them afther extensive test]

do you call them not expert? right?

afther say that, i kill file you and Ian Collins
[i rememeber kill file both... why i see their post?]
because not interested from wrong answers

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

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

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

csiph-web