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

Groups > comp.lang.misc > #3851 > unrolled thread

Compiling and linking code from different places in the file system

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

Contents

  Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-01 14:40 +0000
    Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-01 14:55 +0000
      Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-02 21:05 +0000
        Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-03 01:18 +0000
          Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-09 01:03 +0000
        Re: Compiling and linking code from different places in the file system Rod Pemberton <NoEmail@trraxvfeqa.prg> - 2018-03-06 06:40 -0500
          Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-06 21:10 +0000
            Re: Compiling and linking code from different places in the file system Rod Pemberton <NoEmail@trraxvfeqa.prg> - 2018-03-07 06:58 -0500
              Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-09 01:23 +0000
                Re: Compiling and linking code from different places in the file system Rod Pemberton <NoEmail@trraxvfeqa.prg> - 2018-03-09 02:28 -0500
                  Re: Compiling and linking code from different places in the file system Rod Pemberton <NoEmail@trraxvfeqa.prg> - 2018-03-09 02:44 -0500
                  Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-09 23:26 +0000
                    Re: Compiling and linking code from different places in the file system Rod Pemberton <NoEmail@trraxvfeqa.prg> - 2018-03-11 07:44 -0400
                      Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-12 21:59 +0000
                        Re: Compiling and linking code from different places in the file system Rod Pemberton <NoEmail@trraxvfeqa.prg> - 2018-03-14 01:45 -0400
                          Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-14 10:59 +0000
        Re: Compiling and linking code from different places in the file system Rod Pemberton <NoEmail@trraxvfeqa.prg> - 2018-03-06 06:40 -0500
          Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-06 21:20 +0000
            Re: Compiling and linking code from different places in the file system Rod Pemberton <NoEmail@trraxvfeqa.prg> - 2018-03-07 06:58 -0500
              Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-09 10:30 +0000
    Re: Compiling and linking code from different places in the file system "James R. Kuyper" <jameskuyper@verizon.net> - 2018-03-01 11:11 -0500
      Re: Compiling and linking code from different places in the file system "James R. Kuyper" <jameskuyper@verizon.net> - 2018-03-01 13:51 -0500
      Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-03 09:48 +0000
    Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-03 12:25 +0000
      Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-03 15:32 +0000
        Re: Compiling and linking code from different places in the file system Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-03-04 07:52 +0000
        Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-04 08:43 +0000
          Re: Compiling and linking code from different places in the file system Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-03-05 07:58 +0000
            Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-06 21:37 +0000
              Re: Compiling and linking code from different places in the file system Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-03-07 21:02 +0000
          Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-05 15:29 +0000
            Re: Compiling and linking code from different places in the file system rugxulo@gmail.com - 2018-03-06 18:23 -0800
            Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-07 04:54 +0000
              Re: Compiling and linking code from different places in the file system Robert Wessel <robertwessel2@yahoo.com> - 2018-03-07 00:33 -0600
                Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-07 09:55 +0000
                Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-07 17:29 +0000
    Re: Compiling and linking code from different places in the file system Rod Pemberton <NoEmail@trraxvfeqa.prg> - 2018-03-06 06:39 -0500
      Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-07 10:44 +0000
        Re: Compiling and linking code from different places in the file system Rod Pemberton <NoEmail@trraxvfeqa.prg> - 2018-03-07 06:57 -0500
          Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-09 10:28 +0000
            Re: Compiling and linking code from different places in the file system Rod Pemberton <NoEmail@trraxvfeqa.prg> - 2018-03-11 07:44 -0400
              Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-12 22:44 +0000
                Re: Compiling and linking code from different places in the file system Rod Pemberton <NoEmail@trraxvfeqa.prg> - 2018-03-14 01:47 -0400
                  Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-14 10:23 +0000
                    Re: Compiling and linking code from different places in the file system "Pascal J. Bourguignon" <pjb@informatimago.com> - 2018-03-14 11:30 +0100
                      Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-14 11:30 +0000
                        Re: Compiling and linking code from different places in the file system "Pascal J. Bourguignon" <pjb@informatimago.com> - 2018-03-14 13:30 +0100
                          Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-14 14:32 +0000
                            Re: Compiling and linking code from different places in the file system "Pascal J. Bourguignon" <pjb@informatimago.com> - 2018-03-14 16:01 +0100
                              Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-14 19:28 +0000
                                Re: Compiling and linking code from different places in the file system "Pascal J. Bourguignon" <pjb@informatimago.com> - 2018-03-15 08:59 +0100
                                  Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-15 19:21 +0000
                                    Re: Compiling and linking code from different places in the file system "Pascal J. Bourguignon" <pjb@informatimago.com> - 2018-03-16 08:08 +0100
                                      Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-16 11:12 +0000
                                        Re: Compiling and linking code from different places in the file system "Pascal J. Bourguignon" <pjb@informatimago.com> - 2018-03-16 16:45 +0100
                                        Re: Compiling and linking code from different places in the file system Andy Walker <anw@cuboid.co.uk> - 2018-03-16 16:09 +0000
                                          Re: Compiling and linking code from different places in the file system "Pascal J. Bourguignon" <pjb@informatimago.com> - 2018-03-16 18:42 +0100
                                          Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-17 18:32 +0000
                                            Re: Compiling and linking code from different places in the file system "Pascal J. Bourguignon" <pjb@informatimago.com> - 2018-03-17 21:37 +0100
                                              Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-17 21:00 +0000
                                                Re: Compiling and linking code from different places in the file system "Pascal J. Bourguignon" <pjb@informatimago.com> - 2018-03-18 11:39 +0100
                                                  Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-18 12:29 +0000
                                            Re: Compiling and linking code from different places in the file system Andy Walker <anw@cuboid.co.uk> - 2018-03-19 13:38 +0000
                                              Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-20 05:40 +0000
                                                Re: Compiling and linking code from different places in the file system Andy Walker <anw@cuboid.co.uk> - 2018-03-20 11:05 +0000
                                                  Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-21 06:03 +0000
                                                    Re: Compiling and linking code from different places in the file system Andy Walker <anw@cuboid.co.uk> - 2018-03-21 18:51 +0000
                                                      Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-21 19:55 +0000
                                                        Re: Compiling and linking code from different places in the file system Andy Walker <anw@cuboid.co.uk> - 2018-03-23 18:03 +0000
                                                          Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-23 20:13 +0000
                                                            Re: Compiling and linking code from different places in the file system Andy Walker <anw@cuboid.co.uk> - 2018-03-24 01:30 +0000
                                                              Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-24 16:48 +0000
                                                                Re: Compiling and linking code from different places in the file system Andy Walker <anw@cuboid.co.uk> - 2018-03-26 19:42 +0100
                                                                  Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-26 22:35 +0100
                                                            Re: Compiling and linking code from different places in the file system "Pascal J. Bourguignon" <pjb@informatimago.com> - 2018-03-24 12:01 +0100
                                                      Re: Compiling and linking code from different places in the file system "Pascal J. Bourguignon" <pjb@informatimago.com> - 2018-03-23 20:58 +0100
                                                Re: Compiling and linking code from different places in the file system "Pascal J. Bourguignon" <pjb@informatimago.com> - 2018-03-23 20:49 +0100
                                              Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-20 18:37 +0000
                                                Re: Compiling and linking code from different places in the file system Andy Walker <anw@cuboid.co.uk> - 2018-03-21 19:33 +0000
                                                  Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-21 20:35 +0000
                                                    Re: Compiling and linking code from different places in the file system "Pascal J. Bourguignon" <pjb@informatimago.com> - 2018-03-23 21:10 +0100
                                                      Re: Compiling and linking code from different places in the file system Marco van de Voort <marcov@toad.stack.nl> - 2018-04-19 06:47 +0000
                                                    Re: Compiling and linking code from different places in the file system Andy Walker <anw@cuboid.co.uk> - 2018-03-27 00:58 +0100
                                                      Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-30 19:55 +0100
                                                  Re: Compiling and linking code from different places in the file system Marco van de Voort <marcov@toad.stack.nl> - 2018-04-19 06:49 +0000
                                                Re: Compiling and linking code from different places in the file system "Pascal J. Bourguignon" <pjb@informatimago.com> - 2018-03-23 21:04 +0100
                                                  Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-23 21:54 +0000
                                                    Re: Compiling and linking code from different places in the file system "Pascal J. Bourguignon" <pjb@informatimago.com> - 2018-03-24 11:22 +0100
                                                      Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-24 12:12 +0000
                                                        Re: Compiling and linking code from different places in the file system "Pascal J. Bourguignon" <pjb@informatimago.com> - 2018-03-24 13:15 +0100
                                                        Re: Compiling and linking code from different places in the file system "Pascal J. Bourguignon" <pjb@informatimago.com> - 2018-03-24 13:36 +0100
                                                          Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-24 14:52 +0000
                                                  Re: Compiling and linking code from different places in the file system Marco van de Voort <marcov@toad.stack.nl> - 2018-04-19 11:06 +0000
                        Re: Compiling and linking code from different places in the file system David Brown <david.brown@hesbynett.no> - 2018-03-14 16:52 +0100
                          Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-14 19:38 +0000
                            Re: Compiling and linking code from different places in the file system "Pascal J. Bourguignon" <pjb@informatimago.com> - 2018-03-15 09:00 +0100
                              Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-15 12:54 +0000
                  Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-14 11:18 +0000
                    Re: Compiling and linking code from different places in the file system "Pascal J. Bourguignon" <pjb@informatimago.com> - 2018-03-14 13:52 +0100
                    Re: Compiling and linking code from different places in the file system Rod Pemberton <NoEmail@trraxvfeqa.prg> - 2018-03-15 06:29 -0400
                      Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-15 20:37 +0000
                        Re: Compiling and linking code from different places in the file system Rod Pemberton <NoEmail@trraxvfeqa.prg> - 2018-03-17 11:51 -0400
                          Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-20 06:31 +0000
                            Re: Compiling and linking code from different places in the file system Rod Pemberton <NoEmail@trraxvfeqa.prg> - 2018-03-20 17:14 -0400
                              Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-21 07:10 +0000
                                Re: Compiling and linking code from different places in the file system Rod Pemberton <NoEmail@trraxvfeqa.prg> - 2018-03-24 01:38 -0400
                                  Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-24 16:10 +0000
                                    Re: Compiling and linking code from different places in the file system Rod Pemberton <NoEmail@trraxvfeqa.prg> - 2018-03-24 20:05 -0400
                                      Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-25 16:55 +0100
    Re: Compiling and linking code from different places in the file system "Pascal J. Bourguignon" <pjb@informatimago.com> - 2018-03-14 13:39 +0100

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

#3945

bartc <bc@freeuk.com> writes:

> On 21/03/2018 19:33, Andy Walker wrote:
>> On 20/03/18 18:37, bartc wrote:
>>> I don't know what the guys at these Unix places were up to. Did they
>>> even sell commercial applications?
>>
>>      ???  Bell Labs was the research arm of AT&T -- as commercial a
>> company as anyone could want.
>
> By Unix places I meant places since then that use Unix or Unix-like
> systems and that sell applications for use by people with those same
> systems.

Well, if you talk about unix applications being sold, then they would
most often come in the form of a bunch of .o files, to be linked on the
target systems by using a makefile!

(Before dynamic libraries were invented, static linking with the various
system libraries of the variousj target systems had to be done at
installation time).


Nowadays, "unix" and "sell application" means macOS, iOS and Android.


-- 
__Pascal J. Bourguignon
http://www.informatimago.com

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

#3970

On 2018-03-23, Pascal J. Bourguignon <pjb@informatimago.com> wrote:
>> By Unix places I meant places since then that use Unix or Unix-like
>> systems and that sell applications for use by people with those same
>> systems.
>
> Well, if you talk about unix applications being sold, then they would
> most often come in the form of a bunch of .o files, to be linked on the
> target systems by using a makefile!

In later times there was alos IBCS (*) Linux supported it for a while, and afaik
it was installed in early kernel 2.0 times.

(*) https://en.wikipedia.org/wiki/Intel_Binary_Compatibility_Standard

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

#3962

On 21/03/18 20:35, bartc wrote:
>> I don't know what the guys at these Unix places were up to. Did they
>>> even sell commercial applications?
>>      ???  Bell Labs was the research arm of AT&T -- as commercial a
>> company as anyone could want.
> By Unix places I meant places since then that use Unix or Unix-like
> systems and that sell applications for use by people with those same
> systems.

	Lots of "research" software gets produced and either sold or else
used and the results sold or licensed.  Personally, I've had very little
to do with Unix commercially;  but companies such as Sun and SGI were
using Unix variants in the '80s and '90s and I'm guessing that they made
money out of doing so.

	May be worth noting that every single one of the world's top 500
supercomputers now runs Linux -- the last Windows machine dropped out in
2015 -- though a few still have non-Linux components.  What they're all
doing is anyone's guess -- Bitcoin mining, weather forecasting, nuclear
physics, cryptography, computer chess, ...? -- but given the cost and
the number of exaFLOPS and megawatts they're using, it seems unlikely
that they're all just playing games.

>> For once in world history, a company did
>> something amazing
> (If that's supposed to include creating the 'C' language, then I
> would have to disagree.)

	As in my PP, it was a commercial company [albeit the research part
of that company]employing a building-full of highly-talented people with
a brief of doing their own thing.  Even more freedom than is/was usually
given to academic research workers.  Inevitably, the results were not
always brilliant or commercially exploitable, but it's a decent guess that
Bell Labs produced at least as much high-quality output as any university
department of comparable size.

>>      It's rather less reasonable to expect a university lecturer or
>> research student or minor software developer with an interesting language
>> or game to pre-compile a binary for your machine, about which he/she knows
>> nothing.
> Why not? How many platforms are there likely to be that someone with
> consumer equipment will want to run it on?
> I think if x86 32/64-bit and ARM 32/64-bit are covered, then that
> covers most of it. [...]

	"Consumer equipment" is your interpolation.  All of the "top 500"
use 64-bit architectures, mostly Intel x86, but there are still a smattering
of other platforms, and that's just the serious high-performance end.  There
is still a lot of legacy equipment out there, which may not be of commercial
interest for new applications, but is still being used either for old software
that nevertheless needs to be kept updated and running, or for historical
interest.  Quite apart from that, it's not just the hardware differences that
need to be accounted for;  eg, a chess-playing program may need to know what
opening books and endgame tablebases the host computer possesses, and where
these are to be found.  The Algol 68G compiler configures itself differently
depending on whether "plotlib", "sql", "curses" and scientific software are
available.  There are tools out there that make it easy [at least, easier]
for people to supply appropriate "configure" scripts and "makefiles".  I
don't expect people supplying free software to go to the extra trouble of
building binaries for all possible users;  I'm grateful to those who do.

-- 
Andy Walker,
Nottingham.

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

#3963

On 27/03/2018 00:58, Andy Walker wrote:
> On 21/03/18 20:35, bartc wrote:
>>> I don't know what the guys at these Unix places were up to. Did they
>>>> even sell commercial applications?
>>>      ???  Bell Labs was the research arm of AT&T -- as commercial a
>>> company as anyone could want.
>> By Unix places I meant places since then that use Unix or Unix-like
>> systems and that sell applications for use by people with those same
>> systems.
> 
>      Lots of "research" software gets produced and either sold or else
> used and the results sold or licensed.  Personally, I've had very little
> to do with Unix commercially;  but companies such as Sun and SGI were
> using Unix variants in the '80s and '90s and I'm guessing that they made
> money out of doing so.
> 
>      May be worth noting that every single one of the world's top 500
> supercomputers now runs Linux -- the last Windows machine dropped out in
> 2015 -- though a few still have non-Linux components.

/My/ supercomputer probably wouldn't.

That these machines use Linux is not that surprising: there must be a 
huge amount of expertise, especially in research departments, in 
building and configuring Linux systems. (Certainly, configuring and 
generally messing about is what I remember predominantly doing trying to 
get it to do anything.)

Windows seems an unlikely choice; it seems so consumer-oriented and 
designed especially to consume as many resources as possible while doing 
as little useful work as possible. Like incessantly downloading new 
upgrades.

But the dominance of Linux and C now seems to have killed any other 
competition. While the complicated systems and peripherals we have now 
makes it harder for new OSes to get started.

(When I first started properly with hardware, there was either no OS at 
all, or there was something that provided a file system, and little 
else. Everything else, /I/ had to program.

That's partly why I find it hard to understand the big fuss about OSes.)


-- 
bartc

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

#3971

On 2018-03-21, Andy Walker <anw@cuboid.co.uk> wrote:
>> I don't know what the guys at these Unix places were up to. Did they
>> even sell commercial applications?
>
> 	???  Bell Labs was the research arm of AT&T -- as commercial a
> company as anyone could want.  For once in world history, a company did
> something amazing -- they employed a significant number of the world's
> cleverest people, and said to them "do whatever you like", knowing that
> all sorts of really good ideas would emerge, whether or not those ideas
> were of direct benefit to AT&T.

(commercial but inhouse is not the same as suitable for a shrinkwrap software
model. Unix and derivatives remain a construction kit with limited cross
version binary compatibility to this day. Which is not a problem for
the communications cupboards it was designed for, but is a problem when the
OS and app vendor differs, and works using different timelines/scales)

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

#3944

bartc <bc@freeuk.com> writes:

> On 19/03/2018 13:38, Andy Walker wrote:
>> On 17/03/18 18:32, bartc wrote:
>
>>> And installation is a separate process. IME, of getting an already
>>> built application in binary format on some distribution medium, onto
>>> the user's machine in usable form.
>>
>>      Yes.  Whatever you decide you want to do in this regard, you put it
>> into a "makefile", and "make" will do it whenever you issue the
>> command [eg]
>> "make install".
>
> I don't know what the guys at these Unix places were up to. Did they
> even sell commercial applications?
>
> In the 80s and 90s, I would distribute apps on floppy disk. The
> customer would insert the disk and then type in a command to start the
> program; that might have been been all the installation needed.
>
> If there was a hard drive, then the program they would start might
> copy the contents to a location on the hard drive.
>
> Configuration (of display, input devices, preferences and other
> matters) might be another program, or be part of the application
>
> The users were non-technical and wouldn't have any idea what a
> makefile was (neither did I at the time).

Programs in the 80s and 90s were distributed in binary form, with a
privative license, and had to be bought for a lot of money.
How many of those programs can you still run nowadays?
(ie. how much of that money did you actually threw out of the window?)
(Well not lost to everybody, Bill Gates is vaccinating Africa and Larry
Ellison bought a Hawaii island).


Contrast that with the software that is distributed in source form with
a freedom preserving license, and that you could compile on your old
unix workstations, on your linux systems, on MacOSX, on Android, and
even sometimes on MS-Windows, even today, and you will be able to
compile and use them still in 50 years!


>> The only difference between that and having a shell script
>> or batch file to do the same is that "make" understands dependencies, so if
>> you tell it that installation depends on some file [eg the executable] and
>> something that that file depends on has changed [eg a source file] then the
>> [in this case] executable will be made first -- automatically.
>
> I don't know how it works now. But when I download an app on my kids'
> smartphones it doesn't look to be like it uses 'make install'. But if
> it does, I don't care because the process is usually reliable and
> transparent.

The difference is that being a _user_ of Android or iPhone, you're
basically raped everytime you use them.


-- 
__Pascal J. Bourguignon
http://www.informatimago.com

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

#3947

On 23/03/2018 20:04, Pascal J. Bourguignon wrote:
> bartc <bc@freeuk.com> writes:

>> The users were non-technical and wouldn't have any idea what a
>> makefile was (neither did I at the time).
> 
> Programs in the 80s and 90s were distributed in binary form, with a
> privative license, and had to be bought for a lot of money.

You mean like I might buy a microprocessor chip without being supplied 
with the schematics? (Or pretty much every other product.)

> How many of those programs can you still run nowadays?
> (ie. how much of that money did you actually threw out of the window?)
> (Well not lost to everybody, Bill Gates is vaccinating Africa and Larry
> Ellison bought a Hawaii island).

Do you have a problem with paying any money for software?

As an employer, it's OK to pay money for premises, computer hardware and 
employees' salaries, but paying for a program that an employee might be 
using full time to help them do their job is a rip-off if you can't 
still use 30 years later?

(How many of those computers are still working? How many /cars/ can 
still be used 30 years later?)

> Contrast that with the software that is distributed in source form with
> a freedom preserving license, and that you could compile on your old
> unix workstations, on your linux systems, on MacOSX, on Android, and
> even sometimes on MS-Windows, even today, and you will be able to
> compile and use them still in 50 years!

I doubt it. Not unless you preserved every other bit of software that is 
involved, and preserved the actual hardware or created a good emulation. 
And, if the software depends on internet resources, you maintained a 
snapshot of the entire internet as it is today.

Software is volatile. It becomes dated and needs to be replaced, like 
everything else.

Anyway when it comes to using ancient software, I've had better luck 
with Windows binaries than anything else. Binaries have fewer 
dependencies than source code which may depend on specific compilers and 
build-tools and libraries.

When archiving a program source to use 50 years hence, don't forget to 
archive also the sources for all the compilers and tools it needs, and 
perhaps for the OS too.

> The difference is that being a _user_ of Android or iPhone, you're
> basically raped everytime you use them.

In what way? Everything app I download on Android is free-of-charge. I 
sometimes pay for specific content, but that is no different to paying 
to see a movie at a theatre/cinema, or buying a printed book. Or do you 
have a problem with IP in general?

-- 
bartc

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

#3950

bartc <bc@freeuk.com> writes:

> On 23/03/2018 20:04, Pascal J. Bourguignon wrote:
>> bartc <bc@freeuk.com> writes:
>
>>> The users were non-technical and wouldn't have any idea what a
>>> makefile was (neither did I at the time).
>>
>> Programs in the 80s and 90s were distributed in binary form, with a
>> privative license, and had to be bought for a lot of money.
>
> You mean like I might buy a microprocessor chip without being supplied
> with the schematics? (Or pretty much every other product.)
>
>> How many of those programs can you still run nowadays?
>> (ie. how much of that money did you actually threw out of the window?)
>> (Well not lost to everybody, Bill Gates is vaccinating Africa and Larry
>> Ellison bought a Hawaii island).
>
> Do you have a problem with paying any money for software?

No. I have problems with paying for shit that becomes obsolete faster
than it takes to say it!


> As an employer, it's OK to pay money for premises, computer hardware
> and employees' salaries, but paying for a program that an employee
> might be using full time to help them do their job is a rip-off if you
> can't still use 30 years later?
>
> (How many of those computers are still working? How many /cars/ can
> still be used 30 years later?)

That's my point: software distributed with licenses preserving your
freedom allow you to use them on new computers 30 years later, even
computers with new processors, and entirely different architectures.
That's the fundamental principle of Universal Turing Machines.

When you aquire binary software with privative licenses (including so
called "shareware", and including if you get it for "free" or even for
free), you get the ripped off.


>> Contrast that with the software that is distributed in source form with
>> a freedom preserving license, and that you could compile on your old
>> unix workstations, on your linux systems, on MacOSX, on Android, and
>> even sometimes on MS-Windows, even today, and you will be able to
>> compile and use them still in 50 years!
>
> I doubt it. Not unless you preserved every other bit of software that
> is involved, and preserved the actual hardware or created a good
> emulation. And, if the software depends on internet resources, you
> maintained a snapshot of the entire internet as it is today.

See for example:
http://informatimago.com/develop/lisp/com/informatimago/small-cl-pgms/wang.html


> Software is volatile. It becomes dated and needs to be replaced, like
> everything else.

No.  This is not an intrinsic property of software.

You have two levels here:

- simple tools, such as a hammer.  A hammer made 200 years ago can still
  be used nowadays as well as any other hammer.  The simple command
  programs defined by unix are of this kind.

- complex systems, such as biological systems.  Life evolved over
  billions of years, and the genes defined 300,000 years ago are still
  as good, since you're using them in your body!  Some sophisticated
  adaptative software can be of this kind.

In both cases, one essential part is that the specifications of the
software be rather generic, modular and "universal".  Something like
make for example.


> Anyway when it comes to using ancient software, I've had better luck
> with Windows binaries than anything else. Binaries have fewer
> dependencies than source code which may depend on specific compilers
> and build-tools and libraries.
>
> When archiving a program source to use 50 years hence, don't forget to
> archive also the sources for all the compilers and tools it needs, and
> perhaps for the OS too.

Definitely.  Or define them against specified APIs that can be
reproduced later.  The URL above gives an example of that.


>> The difference is that being a _user_ of Android or iPhone, you're
>> basically raped everytime you use them.
>
> In what way? Everything app I download on Android is free-of-charge. I
> sometimes pay for specific content, but that is no different to paying
> to see a movie at a theatre/cinema, or buying a printed book. Or do
> you have a problem with IP in general?

You're giving away your brains!

https://www.youtube.com/watch?v=c8la-OjoZCA


-- 
__Pascal J. Bourguignon
http://www.informatimago.com

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

#3952

On 24/03/2018 10:22, Pascal J. Bourguignon wrote:
> bartc <bc@freeuk.com> writes:

>> (How many of those computers are still working? How many /cars/ can
>> still be used 30 years later?)
> 
> That's my point: software distributed with licenses preserving your
> freedom allow you to use them on new computers 30 years later, even
> computers with new processors, and entirely different architectures.
> That's the fundamental principle of Universal Turing Machines.

That's a fantasy.

Software evolves. Machines evolve. Languages evolve. People's 
expectations evolve. Requirements and specifications evolve.

(Actually many of the devices I have seem to spend much of their time 
updating themselves, even every few days.)

I still don't see why it's OK to spend $1000 on a machine, full of 
private, closed source electronic know-how, that is a heap of junk in 
ten years, but it's not OK to spend a similar amount for software which 
is apparently expected to last forever.

BTW Linux is apparently open source software. But that's no good at all 
to me because I have no idea how to go about rebuilding it for a 
different machine.

Being open source is not enough - you need additional bits and pieces, 
and extra skills.

In which case you might as well apply the effort to writing new 
software, and get rid of the considerable baggage that can be acquired 
(eg. the C language).


> See for example:
> http://informatimago.com/develop/lisp/com/informatimago/small-cl-pgms/wang.html

I was thinking of something more practical.

I have a netbook running Ubuntu, I think version 10, which is apparently 
to old to be able to upgrade anything on it. And this stuff is open 
source, right? Fat lot of good that is in this case!

>> Software is volatile. It becomes dated and needs to be replaced, like
>> everything else.
> 
> No.  This is not an intrinsic property of software.
> 
> You have two levels here:
> 
> - simple tools, such as a hammer.  A hammer made 200 years ago can still
>    be used nowadays as well as any other hammer.  The simple command
>    programs defined by unix are of this kind.

Is that an upper case hammer or lower case hammer?

See, immediately you've got a problem if you pick up the wrong one, as 
they are not compatible.

Unix is like C in that this pile of complexity from the 1970s seems to 
have ensconced itself in this role of alternative, hippy-style 'free' 
OS, and is not going anywhere.

I'm not saying Windows is superior (I just dislike Windows a lot less 
and it lets me do my own thing), but it seems to have stifled any sort 
of competition.

It doesn't seem to be possible for anyone to come up with an OS that is 
simple and lightweight that is not intimately related to Unix, any of 
the Unix derivatives, and is not written in C; another bugbear.

(Many years ago I was building board-based computers and was able to run 
programs on them to do interesting things without benefit of any OS at 
all, and without needing to use C. Such bliss...)

> - complex systems, such as biological systems.  Life evolved over
>    billions of years, and the genes defined 300,000 years ago are still
>    as good, since you're using them in your body!  Some sophisticated
>    adaptative software can be of this kind.

This is a biological system that keeps going wrong, is susceptible to 
bugs, and that dies out after a few decades, requiring a reboot each 
generation. Not a good example.

> In both cases, one essential part is that the specifications of the
> software be rather generic, modular and "universal".  Something like
> make for example.

Aargh!!! Please don't mention that word again.

I've recently considerably scaled down my interactions with the C 
language, with writing it, generating it, delving into other people's 
code, or grappling with open source software that revolves around 'make'.

I'm concentrating on developing my own languages and tools once again 
and without having to kowtow to C or anything else; much more relaxing 
and rewarding.

> You're giving away your brains!
> 
> https://www.youtube.com/watch?v=c8la-OjoZCA

Sorry, I lasted about 10 seconds; what's the remaining 1 hour 36 minutes 
supposed to be about?

-- 
bartc

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

#3953

bartc <bc@freeuk.com> writes:

> On 24/03/2018 10:22, Pascal J. Bourguignon wrote:
>> bartc <bc@freeuk.com> writes:
>
>>> (How many of those computers are still working? How many /cars/ can
>>> still be used 30 years later?)
>>
>> That's my point: software distributed with licenses preserving your
>> freedom allow you to use them on new computers 30 years later, even
>> computers with new processors, and entirely different architectures.
>> That's the fundamental principle of Universal Turing Machines.
>
> That's a fantasy.
>
> Software evolves. Machines evolve. Languages evolve. People's
> expectations evolve. Requirements and specifications evolve.

And this is a problem!

http://longnow.org

-- 
__Pascal J. Bourguignon
http://www.informatimago.com

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

#3954

bartc <bc@freeuk.com> writes:

> I still don't see why it's OK to spend $1000 on a machine, full of
> private, closed source electronic know-how, that is a heap of junk in
> ten years, but it's not OK to spend a similar amount for software
> which is apparently expected to last forever.

The problem is not that you pay, it's that you don't have the source,
and the license is privative of your freedom to continue using it (and if
the software is badly designed and need it, to update it) for ten or
thousands of years.

Program libraries should also be legacy that your heirs can inherit!
If you spend so much on them, they aught to have some value!


> BTW Linux is apparently open source software. But that's no good at
> all to me because I have no idea how to go about rebuilding it for a
> different machine.
>
> Being open source is not enough - you need additional bits and pieces,
> and extra skills.

You need also skills to read books. Inheriting a book libraries should
motivate you to learn reading…


> In which case you might as well apply the effort to writing new
> software, and get rid of the considerable baggage that can be acquired
> (eg. the C language).

This is obviously a big, but entirely different question.
If you write software that must last long, don't write it in the fucking
language du jour invented by the latest newbie (the programmer
population doubles every 5 years, which means 50% of the programmers are
unwashed newbies with less than 5 years of experience!).
Instead, write your software in programming languages that have passed
the proof of time: Fortran (60 years), Lisp (59 years), or if you want
to take risks, C which is 49 years young…


>>> Software is volatile. It becomes dated and needs to be replaced, like
>>> everything else.
>>
>> No.  This is not an intrinsic property of software.
>>
>> You have two levels here:
>>
>> - simple tools, such as a hammer.  A hammer made 200 years ago can still
>>    be used nowadays as well as any other hammer.  The simple command
>>    programs defined by unix are of this kind.
>
> Is that an upper case hammer or lower case hammer?

It's a universal hammer.

See, this is the problem I'm denouncing.

A programmer who would write a upper case hammer software, when
he could as well write a universal hammer software is a fucking bitch!



> See, immediately you've got a problem if you pick up the wrong one, as
> they are not compatible.
>
> Unix is like C in that this pile of complexity from the 1970s seems to
> have ensconced itself in this role of alternative, hippy-style 'free'
> OS, and is not going anywhere.
>
> I'm not saying Windows is superior (I just dislike Windows a lot less
> and it lets me do my own thing), but it seems to have stifled any sort
> of competition.
>
> It doesn't seem to be possible for anyone to come up with an OS that
> is simple and lightweight that is not intimately related to Unix, any
> of the Unix derivatives, and is not written in C; another bugbear.
>
> (Many years ago I was building board-based computers and was able to
> run programs on them to do interesting things without benefit of any
> OS at all, and without needing to use C. Such bliss...)

All this is not due to programming or computer science constraints, but
only due to the economic and financial system you're slaving for.

Notice the contraste between the http://longnow.org/ purposes and the
financial quarter horizon under which most current software development
occurs. 


>> - complex systems, such as biological systems.  Life evolved over
>>    billions of years, and the genes defined 300,000 years ago are still
>>    as good, since you're using them in your body!  Some sophisticated
>>    adaptative software can be of this kind.
>
> This is a biological system that keeps going wrong, is susceptible to
> bugs, and that dies out after a few decades, requiring a reboot each
> generation. Not a good example.

Better than MS-Windows which requires a reboot everyday!


> I'm concentrating on developing my own languages and tools once again
> and without having to kowtow to C or anything else; much more relaxing
> and rewarding.

Indeed.

>> You're giving away your brains!
>>
>> https://www.youtube.com/watch?v=c8la-OjoZCA
>
> Sorry, I lasted about 10 seconds; what's the remaining 1 hour 36
> minutes supposed to be about?

Take the time!

-- 
__Pascal J. Bourguignon
http://www.informatimago.com

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

#3955

On 24/03/2018 12:36, Pascal J. Bourguignon wrote:
> bartc <bc@freeuk.com> writes:
> 
>> I still don't see why it's OK to spend $1000 on a machine, full of
>> private, closed source electronic know-how, that is a heap of junk in
>> ten years, but it's not OK to spend a similar amount for software
>> which is apparently expected to last forever.
> 
> The problem is not that you pay, it's that you don't have the source,
> and the license is privative of your freedom to continue using it (and if
> the software is badly designed and need it, to update it) for ten or
> thousands of years.
> 
> Program libraries should also be legacy that your heirs can inherit!
> If you spend so much on them, they aught to have some value!

We're already past that point. People no longer own their own physical 
copies of books or music or movies. It's all based on cloud storage.

If they manage to get a local copy, it will be on a device and/or in a 
format that might last a decade, if they're lucky. (And which is 
fragile; try hitting it with that hammer. A book however will sustain 
little damage. Actually I've used a book to support a jack while 
changing a wheel, to even the load a little. I could still read it 
afterwards. Don't try it with an iPad.)

> 
>> BTW Linux is apparently open source software. But that's no good at
>> all to me because I have no idea how to go about rebuilding it for a
>> different machine.
>>
>> Being open source is not enough - you need additional bits and pieces,
>> and extra skills.
> 
> You need also skills to read books. Inheriting a book libraries should
> motivate you to learn reading…

Everything about a book is open source. You're saying everyone should be 
an expert papermaker, should know how to source and blend inks, be able 
to create a printing press, and be a bookbinder?

And that's before we start thinking about revising the content; are we 
also supposed to be experts in the book's subject, or experienced novelists?

With a big project like a complex OS, being open source is a tiny part 
of the picture.

(And for those who do manage, the result seems to be a hundred, 
incompatible versions of Linux.)

> This is obviously a big, but entirely different question.
> If you write software that must last long, don't write it in the fucking
> language du jour invented by the latest newbie (the programmer
> population doubles every 5 years, which means 50% of the programmers are
> unwashed newbies with less than 5 years of experience!).
> Instead, write your software in programming languages that have passed
> the proof of time: Fortran (60 years), Lisp (59 years), or if you want
> to take risks, C which is 49 years young…

Fortran is limited (although it's the best of that bunch). Lisp is only 
half a language (somebody forgot to give it some syntax) and introduces 
a lot of complexities that making coding harder than it need be.

C looks like something thrown together over a drunken weekend by a 
couple of students, and intended as a joke. Or to meet some deadline for 
an assignment. Yet people are still taking it seriously half a century 
later.

I don't think there /is/ a language in which you'd want to write code 
intended for posterity. Except perhaps pseudo-code.

Python? Which exact version and sub-version? What collection of third 
party libraries is needed, and what exact version of each? What exact 
version of pip is needed for that lot? What version of pip is needed to 
download the latest version of pip? It all just about versions and 
libraries and one-liners.

All programming languages are inelegant to some extent, and of their 
time. (Think about what programming language would be used in Heaven, 
and what machine and what OS. The very idea is ludicrous.)

Having said that, and since we still have to program in the here and 
now, there are degrees of elegance:

   #include <stdio.h>
   printf("%s %lld %f\n", a, b, c);       # C

   println a, b, c                        # one of mine

The second example is a couple of steps nearer to pseudo-code.

>> Is that an upper case hammer or lower case hammer?
> 
> It's a universal hammer.

Not on Unix. You have to say 'hammer', and not 'Hammer' or 'HAMMER' or 
any of the other 61 combinations, which can all mean something else.

A workman doesn't have that trouble asking his apprentice for the 
hammer, so why here?

Looked at as an outsider, Unix is appallingly bad and unfriendly.

-- 
bartc

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

#3972

On 2018-03-23, Pascal J. Bourguignon <pjb@informatimago.com> wrote:
>
> Programs in the 80s and 90s were distributed in binary form, with a
> privative license, and had to be bought for a lot of money.
> How many of those programs can you still run nowadays?

More than that I run Unix programs in unmodified form from that era. And
with good reason.

> Contrast that with the software that is distributed in source form with
> a freedom preserving license, and that you could compile on your old
> unix workstations, on your linux systems, on MacOSX, on Android, and
> even sometimes on MS-Windows, even today, and you will be able to
> compile and use them still in 50 years!

It will probably already fail to compile when you transition from one debian
stable to the next.  Let alone when some major component (like a widgetset)
changes version (with the old one soon unsupported).

Note that this is the practice. In theory source level compilability could
be very durable too, but it doesn't seem to be an objective.

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

#3905

On 14/03/18 12:30, bartc wrote:
> On 14/03/2018 10:30, Pascal J. Bourguignon wrote:
>> bartc <bc@freeuk.com> writes:
> 
>>> (I don't use makefiles because I don't think any of my C compilers
>>> have a working version. Or if they do, it invariably reports some
>>> error or other a few lines into the makefile, and I won't have a clue
>>> how to fix it. While my other languages don't have such a concept.)
>>
>> You don't know what make and makefiles are.  It's not a "C concept"!
> 
> So, where does the program to run the makefile come from?
> 
> On Windows, I've only seem them associated with C compilers, if they
> even have one.
> 

The first version of "make" that I used on Windows (it was actually a
DOS program, but I ran it under Windows 3.1) came with a Pascal compiler
and I used it primarily for assembly.

"make" is certainly traditional for C (and C++) programs, but is not at
all restricted to that.  I also use it for assembly code, LaTeX
documentation, some types of graphics work, and for generating gettext
files in some of my Python coding (for multiple language support).  It
is a handy general-purpose tool.

But it is a powerful and complex tool, and some makefiles are rather
complex.  It's debugging facilities are rather limited, and it has a
some oddities (like requiring tab characters, not spaces, for
indentation).

Often, however, very simple makefiles are sufficient - sometimes the
default rules are good enough.  On a *nix system, or a Windows system
with suitable utilities (like msys2 and mingw), you can write a C file
called "prog.c" and generate an executable by just writing "make prog".
 You really don't get simpler than /no/ makefile at all.

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

#3907

On 14/03/2018 15:52, David Brown wrote:
> On 14/03/18 12:30, bartc wrote:

>> On Windows, I've only seem them associated with C compilers, if they
>> even have one.
>>
> 
> The first version of "make" that I used on Windows (it was actually a
> DOS program, but I ran it under Windows 3.1) came with a Pascal compiler
> and I used it primarily for assembly.
> 
> "make" is certainly traditional for C (and C++) programs, but is not at
> all restricted to that.  I also use it for assembly code, LaTeX
> documentation, some types of graphics work, and for generating gettext
> files in some of my Python coding (for multiple language support).  It
> is a handy general-purpose tool.
> 
> But it is a powerful and complex tool, and some makefiles are rather
> complex.  It's debugging facilities are rather limited, and it has a
> some oddities (like requiring tab characters, not spaces, for
> indentation).
> 
> Often, however, very simple makefiles are sufficient - sometimes the
> default rules are good enough.  On a *nix system, or a Windows system
> with suitable utilities (like msys2 and mingw), you can write a C file
> called "prog.c" and generate an executable by just writing "make prog".
>   You really don't get simpler than /no/ makefile at all.

make prog doesn't work with DMC, lccwin or Pelles C (as far as I got 
before giving up).

So you're saying I can build programs without makefiles, provided I 
download half of Unix first in the form of msys and cygwin? OK.

But typical compilers will let you do: cp prog.c -oprog.exe, where cp is 
the compiler program.

If that's too difficult, then a batch file like the following cc.bat file:

   cp %1.c -o%1.exe

will let you type:

   cc prog

A one-line batch file eliminates the need to download msys2; how about that.

-- 
bartc

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

#3909

bartc <bc@freeuk.com> writes:

> On 14/03/2018 15:52, David Brown wrote:
>> On 14/03/18 12:30, bartc wrote:
>
>>> On Windows, I've only seem them associated with C compilers, if they
>>> even have one.
>>>
>>
>> The first version of "make" that I used on Windows (it was actually a
>> DOS program, but I ran it under Windows 3.1) came with a Pascal compiler
>> and I used it primarily for assembly.
>>
>> "make" is certainly traditional for C (and C++) programs, but is not at
>> all restricted to that.  I also use it for assembly code, LaTeX
>> documentation, some types of graphics work, and for generating gettext
>> files in some of my Python coding (for multiple language support).  It
>> is a handy general-purpose tool.
>>
>> But it is a powerful and complex tool, and some makefiles are rather
>> complex.  It's debugging facilities are rather limited, and it has a
>> some oddities (like requiring tab characters, not spaces, for
>> indentation).
>>
>> Often, however, very simple makefiles are sufficient - sometimes the
>> default rules are good enough.  On a *nix system, or a Windows system
>> with suitable utilities (like msys2 and mingw), you can write a C file
>> called "prog.c" and generate an executable by just writing "make prog".
>>   You really don't get simpler than /no/ makefile at all.
>
> make prog doesn't work with DMC, lccwin or Pelles C (as far as I got
> before giving up).
>
> So you're saying I can build programs without makefiles, provided I
> download half of Unix first in the form of msys and cygwin? OK.
>
> But typical compilers will let you do: cp prog.c -oprog.exe, where cp
> is the compiler program.
>
> If that's too difficult, then a batch file like the following cc.bat file:
>
>   cp %1.c -o%1.exe
>
> will let you type:
>
>   cc prog
>
> A one-line batch file eliminates the need to download msys2; how about that.

Trivial case is trivial.  DUH!

-- 
__Pascal J. Bourguignon
http://www.informatimago.com

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

#3911

On 15/03/2018 08:00, Pascal J. Bourguignon wrote:
> bartc <bc@freeuk.com> writes:
> 
>> On 14/03/2018 15:52, David Brown wrote:

>>> ...generate an executable by just writing "make prog".
>>>    You really don't get simpler than /no/ makefile at all.

>> But typical compilers will let you do: cp prog.c -oprog.exe, where cp
>> is the compiler program.
>>
>> If that's too difficult, then a batch file like the following cc.bat file:
>>
>>    cp %1.c -o%1.exe
>>
>> will let you type:
>>
>>    cc prog
>>
>> A one-line batch file eliminates the need to download msys2; how about that.
> 
> Trivial case is trivial.  DUH!

The example to show the advantage of 'make' was equally trivial: 'make 
prog'.

I know that C doesn't have a module system, so I know that is not doing 
anything clever like starting with prog.c and locating all the dependent 
source files of the whole project.

But that is exactly what one of my compilers does:

   qc prog

will recursively locate all imports used by prog and create a binary 
file containing the whole program.

Who needs 'make'?

-- 
bartc

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

#3898

On 14/03/2018 05:47, Rod Pemberton wrote:
> On Mon, 12 Mar 2018 22:44:22 +0000
> James Harris <james.harris.1@gmail.com> wrote:
> 
> <snip>
> 
>> 3. The make command is, if anything, too flexible for building
>> programs, and that leads to some crazy makefiles. Rather than have
>> that flexibility in each makefile it may be better to have some
>> universal rules to which limited but sufficient tweaks can be applied.
> 
> I happen to like DOS .bat files, but these are a) for DOS only, b) for
> simpler projects.
> 
>> 4. Unfortunately, make is a security risk. When you run make on
>> someone else's makefile you often don't know which commands it will
>> run under your userid.
> 
> I think that's true of any executable in a privileged environment.
> AFAIK, your only option, if this is a concern, is to build in a
> non-privileged account, at least for Unix or Linux etc.  VMS had ACLs.
> IIRC, SysV had the ability to set per user privileges for executables.
> I don't recall what Stratus Continuum's did here for security ...

What I have in mind to deal with this problem:

Imagine a project were to be distributed as source files. It would come 
with configuration files which tell the "build system" what it needs to 
know about the source files, things like

   * what word size or sizes each requires
   * what CPU modes or architectures each requires
   * any other limitations of each source file

They would come with the project source files.

By contrast, the user would have a configuration file which says which 
compilers or assemblers to use for the kinds of attributes which can be 
specified about the source files. Therefore, the only commands which 
would be runnable would be those the user chooses.


> 
>> 5. At some point I want to link program hierarchies with the
>> universal naming system we've discussed before, and get files from
>> the internet, using the local file system to cache them. The make
>> program won't do any of that.
> 
> Uh ...
> 
>> 6. Automatic configuration is very limited under make.
>>
>> This has come to a head now because I have reached a point with other
>> things where I want multiple object files to be built from each
>> source file, and need greater automaticity - i.e. where the build
>> script works out which compilers to use, which 'include folders' to
>> specify to the compiler, which object modules to link together when
>> invoking the linker, and so on.
> 
> Multiple object files?  Cross-compiling for multiple targets?

Yes, I am looking to be able to pre-build object files for /many/ 
targets. Imagine a folder T containing some assembly source files such 
as Nasm sources for x86-32 code. There would still be many types of 
object files which could be generated therefrom.

If a certain source file were named

   src/T/S.nasm

it could be assembled to become these object files:

   obj/T/i1/S.nasm.o
   obj/T/i2/S.nasm.o
   obj/T/i3/S.nasm.o
   obj/T/i4/S.nasm.o
   obj/T/i5/S.nasm.o

and so on. Each of those object files would have been derived from the 
same original file, S.nasm.

Naturally, there could be multiple source files in the folder src/T. 
Each of them would be assembled to the subfolders in obj/T. Each of the 
iN subfolders would contain the output of the assembler relating to a 
package of measures such as

   * object file type (ELF32, COFF, win32)
   * calling convention (many possibilities)
   * optimisation type (basically for space or speed)

In other words,

   i1 could be ELF32, cdecl, unoptimised
   i2 could be ELF32, cdecl, optimised for speed
   i3 could be ELF32, stdcall, unoptimised
   i4 could be ELF32, stdcall, optimised for speed

etc.

At the moment I cannot think of any meaningful way to specify the 
object-type attributes individually, hence the idea to combine them into 
a single numbered folder such as i3.

Each object file could be seen as an "instance" of the source file. If a 
source file were to change then all the instances which were made from 
it would have to be remade.

The above shows that quite a lot of instances can be made even from some 
highly specific assembly language source. A piece of portable HLL code 
could have many more instances derived from it, including for different 
architectures if it can be cross compiled.

That was rather a long way to answer your question but, yes, the idea is 
to cross compile for multiple targets, and variants of those targets.


-- 
James Harris

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

#3902

James Harris <james.harris.1@gmail.com> writes:

> On 14/03/2018 05:47, Rod Pemberton wrote:
>> On Mon, 12 Mar 2018 22:44:22 +0000
>> James Harris <james.harris.1@gmail.com> wrote:
>>
>> <snip>
>>
>>> 3. The make command is, if anything, too flexible for building
>>> programs, and that leads to some crazy makefiles. Rather than have
>>> that flexibility in each makefile it may be better to have some
>>> universal rules to which limited but sufficient tweaks can be applied.
>>
>> I happen to like DOS .bat files, but these are a) for DOS only, b) for
>> simpler projects.
>>
>>> 4. Unfortunately, make is a security risk. When you run make on
>>> someone else's makefile you often don't know which commands it will
>>> run under your userid.
>>
>> I think that's true of any executable in a privileged environment.
>> AFAIK, your only option, if this is a concern, is to build in a
>> non-privileged account, at least for Unix or Linux etc.  VMS had ACLs.
>> IIRC, SysV had the ability to set per user privileges for executables.
>> I don't recall what Stratus Continuum's did here for security ...
>
> What I have in mind to deal with this problem:
>
> Imagine a project were to be distributed as source files. It would
> come with configuration files which tell the "build system" what it
> needs to know about the source files, things like
>
>   * what word size or sizes each requires
>   * what CPU modes or architectures each requires
>   * any other limitations of each source file
>
> They would come with the project source files.
>
> By contrast, the user would have a configuration file which says which
> compilers or assemblers to use for the kinds of attributes which can
> be specified about the source files. Therefore, the only commands
> which would be runnable would be those the user chooses.
>
>
>>
>>> 5. At some point I want to link program hierarchies with the
>>> universal naming system we've discussed before, and get files from
>>> the internet, using the local file system to cache them. The make
>>> program won't do any of that.
>>
>> Uh ...
>>
>>> 6. Automatic configuration is very limited under make.
>>>
>>> This has come to a head now because I have reached a point with other
>>> things where I want multiple object files to be built from each
>>> source file, and need greater automaticity - i.e. where the build
>>> script works out which compilers to use, which 'include folders' to
>>> specify to the compiler, which object modules to link together when
>>> invoking the linker, and so on.
>>
>> Multiple object files?  Cross-compiling for multiple targets?
>
> Yes, I am looking to be able to pre-build object files for /many/
> targets. Imagine a folder T containing some assembly source files such
> as Nasm sources for x86-32 code. There would still be many types of
> object files which could be generated therefrom.
>
> If a certain source file were named
>
>   src/T/S.nasm
>
> it could be assembled to become these object files:
>
>   obj/T/i1/S.nasm.o
>   obj/T/i2/S.nasm.o
>   obj/T/i3/S.nasm.o
>   obj/T/i4/S.nasm.o
>   obj/T/i5/S.nasm.o
>
> and so on. Each of those object files would have been derived from the
> same original file, S.nasm.
>
> Naturally, there could be multiple source files in the folder
> src/T. Each of them would be assembled to the subfolders in
> obj/T. Each of the iN subfolders would contain the output of the
> assembler relating to a package of measures such as
>
>   * object file type (ELF32, COFF, win32)
>   * calling convention (many possibilities)
>   * optimisation type (basically for space or speed)
>
> In other words,
>
>   i1 could be ELF32, cdecl, unoptimised
>   i2 could be ELF32, cdecl, optimised for speed
>   i3 could be ELF32, stdcall, unoptimised
>   i4 could be ELF32, stdcall, optimised for speed
>
> etc.
>
> At the moment I cannot think of any meaningful way to specify the
> object-type attributes individually, hence the idea to combine them
> into a single numbered folder such as i3.
>
> Each object file could be seen as an "instance" of the source file. If
> a source file were to change then all the instances which were made
> from it would have to be remade.
>
> The above shows that quite a lot of instances can be made even from
> some highly specific assembly language source. A piece of portable HLL
> code could have many more instances derived from it, including for
> different architectures if it can be cross compiled.
>
> That was rather a long way to answer your question but, yes, the idea
> is to cross compile for multiple targets, and variants of those
> targets.

So, again, the question is what build system you are using.

One of the oldest is to use makefiles, and you can solve this problem
with make without any difficulties.

I've also advised scons, but of course, scons is written in Python, and
it may be untasty to use another programming language.

In the case of Common Lisp, I mentionned asdf, but before that other
systems building systems were defined (eg. defsystem) and programmed in
Common Lisp of course.  Without using a pre-defined build system, it's
customary to define a loader.lisp file that contains the lisp program
used to build the rest of the lisp system.  It's all rather easy and
trivial.

As a programmer, you should be able to write easily the code
corresponding to your specification.


For example:

    struct {
           const char* name;
           const char* option;
    } optimizations[]={{"unoptimized",""},
                       {"optimized-for-speed","-O1"}};

    struct {
           const char* name;
           const char* option;
    } calls[]={{"cdecl","-tradi"},
               {"stdcall","-lang c11"}};


    for(int o=0;o<(sizeof(optimizations)/sizeof(optimizations[0]));o++){
        for(int c=0;c<(sizeof(calls)/sizeof(calls[0]));c++){
            char name[128];
            sprintf(name,"obj/T/%s--%s",calls[c].name,optimizations[o].name);
            // …
            if(0==fork()){
                execv(cc,argv);
            }}}
    
So the point here is that you can just write your own program in the
language you know to build algorithmically your system.


-- 
__Pascal J. Bourguignon
http://www.informatimago.com

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

#3910

On Wed, 14 Mar 2018 11:18:02 +0000
James Harris <james.harris.1@gmail.com> wrote:

> On 14/03/2018 05:47, Rod Pemberton wrote:
> > On Mon, 12 Mar 2018 22:44:22 +0000
> > James Harris <james.harris.1@gmail.com> wrote:

<snip>

> What I have in mind to deal with this problem:
> 
> Imagine a project were to be distributed as source files. It would
> come with configuration files which tell the "build system" what it
> needs to know about the source files, things like
> 
>    * what word size or sizes each requires

Can't these be generated from parsing the code?

E.g., many years ago I created a mainframe program that would read a
database file of any format, and allow you to display the records
appropriate to the specific database.  The structure for the database
records was needed by the display program, but that couldn't be
statically compiled in via an include file, because the app needed to
work for multiple databases with different formats and different
includes. So, I used an AWK script to parse each include file, and emit
a file with the structure in a format that display program could use,
dynamically, for each database, respectively.  Then, you just started
the display app, passed it the name of the database to display, and
also the name of the file with the reformatted database structure for
the respective database.

>    * what CPU modes or architectures each requires

Should the code (or coder) decide this?  What if the mode or
architecture isn't available?

>    * any other limitations of each source file

Wouldn't limitations go against the portable code concept?  ;-)

> They would come with the project source files.
> 
> By contrast, the user would have a configuration file which says
> which compilers or assemblers to use for the kinds of attributes
> which can be specified about the source files.

Wouldn't each compiler or assembler already have their own
required format?  E.g., I can't envision a Linux makefile working with
Turbo C, nor vice-versa.  I.e., how do you intend to emit a
compiler native makefile from your build script? ...

> Therefore, the only
> commands which would be runnable would be those the user chooses.

Well, total user control is good.

So, I'm guessing that you're attempting to separate the architecture
specifics from the code specifics.

Is the compiling distributed across multiple platforms too?  If so,
then in theory, the appropriate architecture can always be used to
compile the code for it.

> Yes, I am looking to be able to pre-build object files for /many/ 
> targets. 

Initial thoughts are:

a) multiple directories, each unique to a specific platform
b) cloud computing with distributed compiling upon the correct
architecture for the code

> Yes, I am looking to be able to pre-build object files for /many/ 
> targets. Imagine a folder T containing some assembly source files
> such as Nasm sources for x86-32 code. There would still be many types
> of object files which could be generated therefrom.
> 
> If a certain source file were named
> 
>    src/T/S.nasm
> 
> it could be assembled to become these object files:
> 
>    obj/T/i1/S.nasm.o
>    obj/T/i2/S.nasm.o
>    obj/T/i3/S.nasm.o
>    obj/T/i4/S.nasm.o
>    obj/T/i5/S.nasm.o

Is this one-command, multiple build? ...

Wouldn't it be easier to have a room with multiple computers, each
running a daemon or other process awaiting commands.  You could
multicast out many of the same commands to all machines:

1) ftp the source packages from control machine
2) unzip/untar the packages
3) configure and make

Obviously, some machines might have different configure and make
processes.  So, some machines would need to translate locally.

> and so on. Each of those object files would have been derived from
> the same original file, S.nasm.
>
> Naturally, there could be multiple source files in the folder src/T. 
> Each of them would be assembled to the subfolders in obj/T. Each of
> the iN subfolders would contain the output of the assembler relating
> to a package of measures such as
> 
>    * object file type (ELF32, COFF, win32)
>    * calling convention (many possibilities)
>    * optimisation type (basically for space or speed)
> 
> In other words,
> 
>    i1 could be ELF32, cdecl, unoptimised
>    i2 could be ELF32, cdecl, optimised for speed
>    i3 could be ELF32, stdcall, unoptimised
>    i4 could be ELF32, stdcall, optimised for speed
> 
> etc.
> 
> At the moment I cannot think of any meaningful way to specify the 
> object-type attributes individually, hence the idea to combine them
> into a single numbered folder such as i3.

What is wrong with multiple cross-compile builds on the same machine,
but passing different command line options for each build?  I.e., the
current way this is done.
 
> Each object file could be seen as an "instance" of the source file.
> If a source file were to change then all the instances which were
> made from it would have to be remade.

Wouldn't it be easier to generate /ONE/ "object" file which could be
used for all machines, e.g., interpretable byte code or JIT compilation,
etc., then distribute it to each machine to do final compilation or
interpretation?

> That was rather a long way to answer your question but, yes, the idea
> is to cross compile for multiple targets, and variants of those
> targets.

I like these ideas best:

a) create one "object" file for all machines, e.g., JIT of Java byte
code or LLVM IR or ANDF etc
b) distributed cloud-computing compile on each specific architecture


Rod Pemberton
-- 
feedback loop:  Russian aggression -> World complains -> Russian
paranoia -> Russian threats -> repeat

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

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

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

csiph-web