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

#3924

bartc <bc@freeuk.com> writes:

> On 17/03/2018 20:37, Pascal J. Bourguignon wrote:
>> bartc <bc@freeuk.com> writes:
>
>
>> Make is not specfic to unix.
>>
>> On the other hand, processing a bunch of source files to obtain a bunch
>> of target files is a generic operation.
>
> OK. Remember that statement....
>
>
>>> Yesterday I went to some trouble to install a new gcc with a working
>>> make program. I tried it on one project, and it turned out the
>>> makefile was only for Unix-like systems, as it needed ./configure to
>>> be run (this was on Windows).
>>
>> Again, MS-Windows is not POSIX, so it should be rejected.
>
> .... because now, it's apparently no longer generic: you need
> something called POSIX to do it, and you can no longer do it on
> MS_Windows.

Make is generic.  But it is up to you to write generic commands in your
makefiles!


One way to do it, is to use the SHELL variable to specify an interpreter
that can be found on all the systems where you run your makefiles, and
to specify the commands in this interpreter language.


I hear that MS-Windows-10 comes with bash and linux tools. Just install
them and be happy with SHELL=/bin/bash, or install and use your own
command interpreter.


But if you want to use sh on unix and command.exe on MS-Windows, you
will have to restrict yourself to the intersection of those command
languages.  It may be very restrictive!




>> It's true that if you want to support non-POSIX systems, you cannot just
>> restrict yourselfl to POSIX commands.
>>
>> This is what tools like maven or ant try to solve, by way of abstracting
>> the commands with platform specific implementations or plugins.  But
>> there will always be another unsupported platform
>
> I would hardly consider MS-Windows an obscure, poorly supported
> platform.

But this is what it is.  I never used a MS-Windows system, ever, in 43
of computer practice…


> (Wasn't this the world's most popular OS at one time? It
> might still be, on PCs.)

Yep.  Shit is also very popular with flies…


> How on earth did people manage without a POSIX conformant 'make'?

They didn't.  Do you manage right now?


> Well in this case they managed it with a script, written in Batch,
> which was much smaller, simpler and more readable than the
> configure/makefile option.

For example, you can write your own interpreter in C, such as do.c:

----(do.c)------------------------------
#include <stdio.h>
int main(int argc,char* argv[]){
    const char* sep="";
    for(int i=1;i<argc;i++){
        printf("%s%s",sep,argv[i]);
        sep=" ";}
    printf("\n");
    fflush(stdout);
    return 0;}
----------------------------------------

and compile it on all your target platforms.

Then you can use it in your makefile:


----(Makefile)--------------------------
SHELL=$(PWD)/do
.SHELLFLAGS=
all:do
do:do.o
	@ link do.o into do
do.o:do.c
	@ compile do.c into do.o
clean::
	@ delete object files 
----------------------------------------


# [pjb@despina :0.0 make]$ make
compile do.c into do.o
link do.o into do
# [pjb@despina :0.0 make]$ make clean
delete object files 
# [pjb@despina :0.0 make]$ 


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

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

#3925

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

> But if you want to use sh on unix and command.exe on MS-Windows, you
> will have to restrict yourself to the intersection of those command
> languages.  It may be very restrictive!

I make minimal use of command.exe as I normally work within my tools. 
Those tools were part-ported to Linux a few years ago, but I then lost 
interest (struggling with the basics such as full keyboard support and 
controlling text on the console being one problem I had no stamina to 
fight).

Anyway, I just have no interest in the capabilities of different command 
shells. So long as they can launch my programs, and do an adequate job 
as a file manager. The same capabilities as the 1970s CP/M probably!

> Yep.  Shit is also very popular with flies…

OK. You don't like Windows, because it it's not as good as Unix, in your 
opinion.

Fine. Other people have different views. Or they needed to make some 
money because at one time no one was buying Unix systems.

> They didn't.  Do you manage right now?

For my own development, it is not a problem at all. It's a non-issue.

I wouldn't have anything to do with it, except some projects that are 
supposed to work on Windows use makefiles which for me is an immediate 
obstacle.

> For example, you can write your own interpreter in C, such as do.c:
> 
> ----(do.c)------------------------------
> #include <stdio.h>
> int main(int argc,char* argv[]){
>      const char* sep="";
>      for(int i=1;i<argc;i++){
>          printf("%s%s",sep,argv[i]);
>          sep=" ";}
>      printf("\n");
>      fflush(stdout);
>      return 0;}
> ----------------------------------------
> 
> and compile it on all your target platforms.

Not sure of the purpose of this example, unless it represents an 
arbitrary application?

But it hurts my eyes a little so I would write it like this in my 
language (also static, compiled, like C):

import main

proc start =
     int i
     for i to nsysparams do
         print sysparams[i]
         if i<nsysparams then print " " fi
     od
     println
end

Count the punctuation marks. Mine has 6. Yours I think has 51.

This I believe demonstrates the difference in mindset between you and 
me. Is there any point in arguing further?

-- 
bartc

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

#3926

On 17/03/18 18:32, bartc wrote:
>>> I just want to compile programs. That is, run a compiler on some
>>> source files. When finished doing that, run a linker on the results.
>>      That, surely, is not all you want to do.  You very possibly also
>> want to run regression tests as you update your programs, to install the
>> executable somewhere more accessible to others than private directories,
>> to install documentation, to back-up the files, and perhaps also to tidy
>> up the files, eg removing "*.o", or even to uninstall the program. ...
> A lot of this I wouldn't consider to be the remit of a system to
> translate source code to executable.

	But that's not what "make" is.  You have compilers for that.

>> [...] But if you want to do
>> something twice, it's usually good practice to record what you did the
>> first time and then be able to say "do that again".  That is what "make"
>> does.  You tell it once, in the "Makefile", how to [eg] install your
>> program,
> 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".  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.

>   not forgetting to update manual entries and documentation,
> What does make know about where I keep my documentation?

	Nothing at all.  It's one of the things you tell it [once!] when you
tell "make" how to install your program.  If you've set it up properly, then
"make" will then do nothing if your documentation is already installed and
hasn't changed, but will install it otherwise.

>							  Or does it
> assume everyone in the world is a Unix user?

	No, but it's rather likely that the commands in your "makefile"
will be different if you write it on a Unix/Linux system from if you
write it on a Windows system.  You can't expect a Unix command to work
on Windows, or vv, unless (a) it is one of the relatively small subset
that have the same name and spec on both systems, or (b) you are running
a Unix emulator on Windows or a Windows emulator on Unix.

> Yesterday I went to some trouble to install a new gcc with a working
> make program. I tried it on one project, and it turned out the
> makefile was only for Unix-like systems, as it needed ./configure to
> be run (this was on Windows).

	Yes.  Most widespread projects [such as "gcc", Firefox, ...] are
downloaded from a site which asks you what OS/hardware you want it for.

> However there was a .bat file supplied for use under Windows (which I
> hadn't spotted) and that eventually worked. It was also 1/4 the size
> of configure+makefile, and clear enough that I could figure how to
> manually compile the core program, and hence how to apply my own
> compiler.

	That's a bit like saying when you buy a new washing machine or
TV or whatever that the instruction booklet contains sections in English,
French, German, Russian. Dutch, Japanese, Urdu, ... whereas when you buy
the same thing in the USA it comes with a booklet entirely in English,
which is a fraction of the size and is all understandable.

	"Configure" is nothing to do with "make" -- except that many
compilers need to know things about the target machine and "configure"
does a lot of work to figure these things out automatically;  so that
"make configure" is a common first step for installing software on a
new computer.

> I need certain information, and the makefile fanatics want to do
> their utmost to hide it from me.

	Blame fanaticism rather than "make".

-- 
Andy Walker,
Nottingham.

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

#3927

On 19/03/2018 13:38, Andy Walker wrote:
> On 17/03/18 18:32, bartc wrote:

...

>> I need certain information, and the makefile fanatics want to do
>> their utmost to hide it from me.
> 
> 	Blame fanaticism rather than "make".

While I agree with that as a basic point isn't there also a case to say 
that make is too flexible and allows users to do crazy things?

When we think about it, flexibility always sounds appealing to us 
individually as it allows us to do things which we could not easily do 
otherwise. But flexibility is not so good when others overuse it and 
then expect us to work with their complex and outre solutions. That's 
why I would say that too much flexibility can be a bad thing.


-- 
James Harris

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

#3932

On 20/03/18 05:40, James Harris wrote:
> On 19/03/2018 13:38, Andy Walker wrote:
>> On 17/03/18 18:32, bartc wrote:
>>> I need certain information, and the makefile fanatics want to do
>>> their utmost to hide it from me.
>>     Blame fanaticism rather than "make".
> While I agree with that as a basic point isn't there also a case to
> say that make is too flexible and allows users to do crazy things?

	No.  Well, not an arguable case.  The same argument could be
put in relation to every non-trivial computer facility, inc every
half-way decent programming language, every OS, every decent editor,
every decent shell/batch system, ....  If you want people to be
unable to do "crazy" things, then you lock them in a rubber sandbox,
put them in strait-jackets and don't give them any pointy tools.
That's not an environment I want to use -- or to provide.

> When we think about it, flexibility always sounds appealing to us
> individually as it allows us to do things which we could not easily
> do otherwise. But flexibility is not so good when others overuse it
> and then expect us to work with their complex and outre solutions.
> That's why I would say that too much flexibility can be a bad thing.

	So how do you propose to arrange that "make" is flexible when
you want to use it, and restricted when others do?  Are you not "others"
from their point of view?

	I suspect also that your idea of "complex and outre" comes from
seeing very general solutions to potentially complex situations, as
opposed to your own specific situation.  I return to the analogy I used
with BartC -- if *you* produce some facility for your own use, and write
instructions for it, you write a leaflet in English.  If you want to
ship that facility around the world, then you have to write French,
German, Russian, Chinese, ... versions, and your simple leaflet turns
into a complicated manual, 95% of which is incomprehensible to the
average punter in Djibouti.  That's why *my* "makefile" is a short,
simple, clear file, and the one I import in order to install *your*
application is incomprehensible.  *You* didn't know what my OS was,
nor the word-length on my computer, nor the CPU chip, nor the flags
I have to supply to the compiler, nor where to install executables to,
nor where manual entries should be put, nor whether I have floating-
point hardware, nor [lots of other things], all of which you have to
find out [eg using "configure"] before your "makefile" can work on
my machine.

-- 
Andy Walker,
Nottingham.

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

#3935

On 20/03/2018 11:05, Andy Walker wrote:
> On 20/03/18 05:40, James Harris wrote:
>> On 19/03/2018 13:38, Andy Walker wrote:
>>> On 17/03/18 18:32, bartc wrote:
>>>> I need certain information, and the makefile fanatics want to do
>>>> their utmost to hide it from me.
>>>      Blame fanaticism rather than "make".
>> While I agree with that as a basic point isn't there also a case to
>> say that make is too flexible and allows users to do crazy things?
> 
> 	No.  Well, not an arguable case.  The same argument could be
> put in relation to every non-trivial computer facility, inc every
> half-way decent programming language, every OS, every decent editor,
> every decent shell/batch system, .... 

IMO programming languages can indeed become too flexible. And the same 
logic applies, i.e. if /we/ want to do something then extreme 
flexibility is, of course, a 'good thing'. We love it. But that's 
because we use the parts of it that we like and are familiar with, and 
that we consider sensible. And when we have to maintain code which 
/someone else/ wrote then we can find that that extreme flexibility has 
allowed him or her to write some genuinely bizarre code. The extreme 
flexibility suddenly becomes no fun at all.

A good example of over-flexibility is goto. /We/ might want to have goto 
available so that we have as much flexibility as possible. But if we 
suddenly find we have to maintain code of someone who over-used goto 
then we may find it's not such a good thing after all.

Another example is Python. It began as a simple and elegant language but 
then accreted loads and loads of clever features. They are not a problem 
if we only ever write our own code; we can stick to a sensible subset. 
But if we have to maintain the code of others then we potentially have 
to know and understand all the other features. The mental burden has 
increased greatly because the language has acquired too much complexity.

A sometimes-quoted design maxim with which I agree in principle is that 
a product is finished not when nothing more can be added but when 
nothing more can be taken away.

In the case in point, make, the same applies. /We/ might use our own 
sensible makefiles. But then as Bart has pointed out, the makefiles 
written by others can be impenetrable. Their great flexibility is also a 
security risk. A makefile can invoke any command on the system and it is 
generally run under our id. That's not good. It would be better if we 
could specify - and limit - the commands a makefile was able to run.

> If you want people to be
> unable to do "crazy" things, then you lock them in a rubber sandbox,
> put them in strait-jackets and don't give them any pointy tools.
> That's not an environment I want to use -- or to provide.
> 
>> When we think about it, flexibility always sounds appealing to us
>> individually as it allows us to do things which we could not easily
>> do otherwise. But flexibility is not so good when others overuse it
>> and then expect us to work with their complex and outre solutions.
>> That's why I would say that too much flexibility can be a bad thing.
> 
> 	So how do you propose to arrange that "make" is flexible when
> you want to use it, and restricted when others do?  Are you not "others"
> from their point of view?

I don't. IMO there's a need for something other than make.

> 
> 	I suspect also that your idea of "complex and outre" comes from
> seeing very general solutions to potentially complex situations, as
> opposed to your own specific situation.  I return to the analogy I used
> with BartC -- if *you* produce some facility for your own use, and write
> instructions for it, you write a leaflet in English.  If you want to
> ship that facility around the world, then you have to write French,
> German, Russian, Chinese, ... versions, and your simple leaflet turns
> into a complicated manual, 95% of which is incomprehensible to the
> average punter in Djibouti.  That's why *my* "makefile" is a short,
> simple, clear file, and the one I import in order to install *your*
> application is incomprehensible.  *You* didn't know what my OS was,
> nor the word-length on my computer, nor the CPU chip, nor the flags
> I have to supply to the compiler, nor where to install executables to,
> nor where manual entries should be put, nor whether I have floating-
> point hardware, nor [lots of other things], all of which you have to
> find out [eg using "configure"] before your "makefile" can work on
> my machine.

Taking the principle of that, rather than just thinking of make, ISTM 
that two configs are needed: one with the source files which says what 
they are capable of, and another that the user controls which says what 
can be done under the user's id. What's wrong with that?


-- 
James Harris

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

#3937

On 21/03/18 06:03, James Harris wrote:
>>> While I agree with that as a basic point isn't there also a case to
>>> say that make is too flexible and allows users to do crazy things?
>>     No.  Well, not an arguable case. [...]
> IMO programming languages can indeed become too flexible. [...]

	I think that if we're to take this much further, then you're going
to have to explain what "flexible" means to you.  Almost any non-trivial
facility is, in some sense, Turing-complete, which means that "anything"
can be programmed as long as a few rather trivial things can.  If you mean
that "anything" can be done in a simple and natural way, then that is [IMO]
both flexible and a Good Thing.  If you are forced to write convoluted code
to do simple things, that's [surely] a Bad Thing.  If you *want* to write
convoluted code [cf the entries for the Obfuscated C competitions], then
how can anyone stop you?

> A good example of over-flexibility is goto. /We/ might want to have
> goto available so that we have as much flexibility as possible. But
> if we suddenly find we have to maintain code of someone who over-used
> goto then we may find it's not such a good thing after all.

	Blame poor programming rather than "flexibility".  There are
situations where "goto" is a good solution to a specific programming
problem;  and many more where it is a bad solution.  The problem of
maintaining such code is not the "go to" but the "come from" -- ie, not
"if X happens then abort to Y" but "looking at Y, how do we get here?".

> Another example is Python. It began as a simple and elegant language
> but then accreted loads and loads of clever features. [...]

	Then not a problem of flexibility, but of complexity.  Yes, it's
all too easy for facilities to accrete things that someone, somewhere
thought they had a use for, and much harder to zap the warts, because
someone, somewhere may be using them.

> In the case in point, make, the same applies. /We/ might use our own
> sensible makefiles. But then as Bart has pointed out, the makefiles
> written by others can be impenetrable. Their great flexibility is
> also a security risk. A makefile can invoke any command on the system
> and it is generally run under our id.

	Nothing to do with flexibility.  The same would apply to any
command that you allow any untrusted user to run on your machine --
including reading PDFs, e-mails and web pages through a possibly
incautious reader/mailer/browser.

>					That's not good. It would be
> better if we could specify - and limit - the commands a makefile was
> able to run.

	You can't.  Not sensibly.  There is no point to a makefile
that cannot do the most obvious things such as compiling, creating
files and moving them around.  You can run "make" in a sandbox if
you like, but that's nothing to do with "make", but rather with the
facilities you get with a security-conscious OS.

[...]
> Taking the principle of that, rather than just thinking of make, ISTM
> that two configs are needed: one with the source files which says
> what they are capable of,

	Do you trust that?  If not, then what is the point of it --
you have to read the source files yourself and determine what they
are capable of.  If so, then what is the point of it, except as part
of the documentation that comes with the application.

>			    and another that the user controls which
> says what can be done under the user's id. What's wrong with that?

	Nothing.  But also nothing at all to do with "make", but with
sandboxing [such as the "restricted shell" of Unix].

-- 
Andy Walker,
Nottingham.

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

#3939

On 21/03/2018 18:51, Andy Walker wrote:
> On 21/03/18 06:03, James Harris wrote:

...

>> 					That's not good. It would be
>> better if we could specify - and limit - the commands a makefile was
>> able to run.
> 
> 	You can't.  Not sensibly.  There is no point to a makefile
> that cannot do the most obvious things such as compiling, creating
> files and moving them around.  You can run "make" in a sandbox if
> you like, but that's nothing to do with "make", but rather with the
> facilities you get with a security-conscious OS.

Well, that was the basic point of the original post, i.e. to come up 
with a new "build system" rather than use make, though I may not have 
made it clear enough that I was talking about writing something bespoke.

> 
> [...]
>> Taking the principle of that, rather than just thinking of make, ISTM
>> that two configs are needed: one with the source files which says
>> what they are capable of,
> 
> 	Do you trust that?  If not, then what is the point of it --
> you have to read the source files yourself and determine what they
> are capable of.  If so, then what is the point of it, except as part
> of the documentation that comes with the application.

The idea is that one config file would say what restrictions or 
limitations source files had (e.g. word size, endianness assumptions, 
required hardware, required libraries etc) and that a completely 
separate config file would tell the build system how to compile files 
which had such attributes.

I have in mind that the /former/ config file would be supplied with the 
source code and would not include any commands. By contrast, the 
/latter/ config file would be supplied by the user running the builds 
(or would be on the system on which the build commands were to be run) 
and it would be the only one which specified commands.

> 
>> 			    and another that the user controls which
>> says what can be done under the user's id. What's wrong with that?
> 
> 	Nothing.  But also nothing at all to do with "make", but with
> sandboxing [such as the "restricted shell" of Unix].

Correct, all of this is nothing to do with make!


-- 
James Harris

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

#3941

On 21/03/18 19:55, James Harris wrote:
[...]
> Well, that was the basic point of the original post, i.e. to come up
> with a new "build system" rather than use make, though I may not have
> made it clear enough that I was talking about writing something
> bespoke.

	You have not explained why you want to re-invent that particular
wheel.  It seems to stem from misunderstandings about "make".

[...]
> The idea is that one config file would say what restrictions or
> limitations source files had (e.g. word size, endianness assumptions,
> required hardware, required libraries etc)

	If your code really has limitations because of such features
[eg, won't work on 16-bit or big-endian machines], then there's not
much more to be said, except "caveat emptor".  But in any case, this
is not a problem with a "build system" but, on the assumption that
your source at least works on your own computer, with exporting to
different environments.

>					     and that a completely
> separate config file would tell the build system how to compile files
> which had such attributes.

	That is, broadly, what "configure" does.  But if you really
want to export your source to [eg] 16-bit machines, then it's the
source that needs to explain [somehow] what the differences are and
how to work around them.  In C, this is usually done by pre-processor
directives ["#ifdef WHATEVER ..."], and it is up to either the
importing user or "configure" to "#define ..." appropriately.

-- 
Andy Walker,
Nottingham.

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

#3946

On 23/03/2018 18:03, Andy Walker wrote:
> On 21/03/18 19:55, James Harris wrote:
> [...]
>> Well, that was the basic point of the original post, i.e. to come up
>> with a new "build system" rather than use make, though I may not have
>> made it clear enough that I was talking about writing something
>> bespoke.
> 
> 	You have not explained why you want to re-invent that particular
> wheel.  It seems to stem from misunderstandings about "make".

Some problems with make.

1. It is more than awkward at handling dependencies which are produced
on the fly. That leads to many makefiles having to split the operations
so you often see

    make depend
    make

The second command uses the dependency files produced by the first. It
would be better to have that stuff handled automatically.

2. I normally prefer commands run to be printed only when they fail in
some way, i.e. default output like this would be handy

    command <errcode>
    stderr output

but only when the command returned a non-zero error code or wrote
something to stderr.

3. The make command is, if anything, too flexible for building programs,
and that leads to some people writing 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.

4. Finally, make is a security risk. When you run make on someone else's
makefile you don't always know which commands it will run under your userid.

That's not to have a go at make. I think it's great. But that list maybe
explains some of the reasons for a custom build system.

> 
> [...]
>> The idea is that one config file would say what restrictions or
>> limitations source files had (e.g. word size, endianness assumptions,
>> required hardware, required libraries etc)
> 
> 	If your code really has limitations because of such features
> [eg, won't work on 16-bit or big-endian machines], then there's not
> much more to be said, except "caveat emptor". 

Even assembly code...?

Take another example, an IRQ handler. Even if written in a HLL it would 
be specific to a certain CPU. That doesn't mean it lacks portability it 
should have.

> But in any case, this
> is not a problem with a "build system" but, on the assumption that
> your source at least works on your own computer, with exporting to
> different environments.

I write as much as possible code to be portable. But there are times 
when some code cannot be completely portable. For example, a lot of my 
code would work with 16-bit, 32-bit or 64-bit integers/pointers, or even 
intermediate sizes such as 18-bit or 36-bit. But it might not work if 
word sizes were too small such as 12-bit or 8-bit.

What all that lot boils down to is a need to say what each source file 
is capable of: minimum number of bits in an integer/pointer, specific 
CPU or CPU mode, and a certain environment such as specific hardware. 
Hence, there seems to be a need to say that by default all code is 
assumed to be completely and totally portable but then allow config 
files to describe restrictions such as those above.

There's no exporting that I am aware of, and only machine-specific 
sources would need to be ported. Most sources just work in different modes.

> 
>> 					     and that a completely
>> separate config file would tell the build system how to compile files
>> which had such attributes.
> 
> 	That is, broadly, what "configure" does.  But if you really
> want to export your source to [eg] 16-bit machines, then it's the
> source that needs to explain [somehow] what the differences are and
> how to work around them.  In C, this is usually done by pre-processor
> directives ["#ifdef WHATEVER ..."], and it is up to either the
> importing user or "configure" to "#define ..." appropriately.
> 

A configure script fails on points 3 and 4, above.

Hopefully the above explains some of the reasons why I started looking 
at a custom system.


-- 
James Harris

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

#3948

On 23/03/18 20:13, James Harris wrote:
>>     You have not explained why you want to re-invent that particular
>> wheel.  It seems to stem from misunderstandings about "make".
> Some problems with make.
> 1. It is more than awkward at handling dependencies which are produced
> on the fly. That leads to many makefiles having to split the operations
> so you often see
>     make depend
>     make
> The second command uses the dependency files produced by the first. It
> would be better to have that stuff handled automatically.

	Arguably;  but that would require "make" to re-determine all the
dependencies.  If it really bothers you, there are ways around it, esp
in Gnu "make".  Personally, I prefer the simpler versions of "make", and
to keep my own "makefile"s very simple too.  But of course people like
to add "features" to everything they use.  The same would happen to your
re-invention if ever it became widespread.

> 2. I normally prefer commands run to be printed only when they fail in
> some way, [...].

	"make -s"?

> 3. The make command is, if anything, too flexible for building
> programs, and that leads to some people writing crazy makefiles.

	I asked earlier what you meant by "flexible", and I'm still not
sure I understand your point.  "Crazy" "makefile"s are mostly written
by other tools, and you are not expected to understand them, any more
than you are expected to understand the parser tables produced by tools
such as Yacc and Lex.

> 4. Finally, make is a security risk. When you run make on someone else's
> makefile you don't always know which commands it will run under your userid.

	"make -n";  &/or use one of the many sandboxing techniques.

> That's not to have a go at make. I think it's great. But that list maybe
> explains some of the reasons for a custom build system.

	Well, it partially explains why you want to write your own version
of "make".  But that seems to be a lot of work to avoid some very minor
inconveniences [to you] of your own "makefile"s;  and it's a whole lot
more work if you want to distribute your re-invention and expect others
to use it [while avoiding those same security problems].

>>> The idea is that one config file would say what restrictions or
>>> limitations source files had (e.g. word size, endianness assumptions,
>>> required hardware, required libraries etc)
>>     If your code really has limitations because of such features
>> [eg, won't work on 16-bit or big-endian machines], then there's not
>> much more to be said, except "caveat emptor". 
> Even assembly code...?
> Take another example, an IRQ handler. Even if written in a HLL it
> would be specific to a certain CPU. That doesn't mean it lacks
> portability it should have.

	Perhaps I wasn't clear.  If your code is [eg] 32-bit specific
[for perhaps excellent reasons], then what are *you* going to do when
someone with a 16-bit machine wants to import your software?  OK, your
config file says "32-bit only";  is that not "end of story"?  The only
way out is to provide either two separate sources or one source with
conditional 16/32-bit sections;  but in that case, "32-bit" is no longer
a *limitation* but an option, to be selected by "configure" or near
equivalent.  Similarly for all other "limitations";  either they are
show-stoppers, or else they require the distributor to supply some way
of getting both [or more] effects by selection at the importing end.

-- 
Andy Walker,
Nottingham.

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

#3957

On 24/03/2018 01:30, Andy Walker wrote:
> On 23/03/18 20:13, James Harris wrote:
>>>      You have not explained why you want to re-invent that particular
>>> wheel.  It seems to stem from misunderstandings about "make".
>> Some problems with make.
>> 1. It is more than awkward at handling dependencies which are produced
>> on the fly. That leads to many makefiles having to split the operations
>> so you often see
>>      make depend
>>      make
>> The second command uses the dependency files produced by the first. It
>> would be better to have that stuff handled automatically.
> 
> 	Arguably;  but that would require "make" to re-determine all the
> dependencies. 

Sure. Is that bad?

> If it really bothers you, there are ways around it, esp
> in Gnu "make". 

Yes, some versions of make allow it. But such techniques are not portable.

> Personally, I prefer the simpler versions of "make", and
> to keep my own "makefile"s very simple too.  But of course people like
> to add "features" to everything they use.  The same would happen to your
> re-invention if ever it became widespread.
> 
>> 2. I normally prefer commands run to be printed only when they fail in
>> some way, [...].
> 
> 	"make -s"?

Close, but it doesn't print the commands even when they fail.

> 
>> 3. The make command is, if anything, too flexible for building
>> programs, and that leads to some people writing crazy makefiles.
> 
> 	I asked earlier what you meant by "flexible", and I'm still not
> sure I understand your point.  "Crazy" "makefile"s are mostly written
> by other tools, and you are not expected to understand them, any more
> than you are expected to understand the parser tables produced by tools
> such as Yacc and Lex.

A makefile can do almost anything you can do under your id, and some 
people who write makefiles should enter obfuscation contests. They could 
be even worse when written by a program.

Rather than that, sometimes, restrictions which enforce a dependable 
structure can be very welcome.

> 
>> 4. Finally, make is a security risk. When you run make on someone else's
>> makefile you don't always know which commands it will run under your userid.
> 
> 	"make -n";  &/or use one of the many sandboxing techniques.

I've found that -n isn't reliable for this. And rather than use 
sandboxing it would surely be easier and safer to control the commands 
which can be run.

Basically, IMO there are enough problems with make to, er, make it 
worthwhile considering a custom solution.

> 
>> That's not to have a go at make. I think it's great. But that list maybe
>> explains some of the reasons for a custom build system.
> 
> 	Well, it partially explains why you want to write your own version
> of "make".  But that seems to be a lot of work to avoid some very minor
> inconveniences [to you] of your own "makefile"s;  and it's a whole lot
> more work if you want to distribute your re-invention and expect others
> to use it [while avoiding those same security problems].

Yes.

> 
>>>> The idea is that one config file would say what restrictions or
>>>> limitations source files had (e.g. word size, endianness assumptions,
>>>> required hardware, required libraries etc)
>>>      If your code really has limitations because of such features
>>> [eg, won't work on 16-bit or big-endian machines], then there's not
>>> much more to be said, except "caveat emptor".
>> Even assembly code...?
>> Take another example, an IRQ handler. Even if written in a HLL it
>> would be specific to a certain CPU. That doesn't mean it lacks
>> portability it should have.
> 
> 	Perhaps I wasn't clear.  If your code is [eg] 32-bit specific
> [for perhaps excellent reasons], then what are *you* going to do when
> someone with a 16-bit machine wants to import your software?  OK, your
> config file says "32-bit only";  is that not "end of story"?  The only
> way out is to provide either two separate sources or one source with
> conditional 16/32-bit sections;  but in that case, "32-bit" is no longer
> a *limitation* but an option, to be selected by "configure" or near
> equivalent.  Similarly for all other "limitations";  either they are
> show-stoppers, or else they require the distributor to supply some way
> of getting both [or more] effects by selection at the importing end.

Well put. Yes, there would normally be other pieces of code for other 
target environments.

To be clear of how I see this all fitting together, the user running the 
builds would have a config file (call it ~/.pbuild.cfg) which said 
things like

* to build 16-bit x86 code from .nasm sources ...
* to build 32-bit x86 code from .nasm sources ...
* to build 64-but x86 code from .nasm sources ...

* to build 16-bit x86 code from .c sources ...
* to build 32-bit x86 code from .c sources ...
* to build 64-but x86 code from .c sources ...

where ... indicates the commands to run.

Given that, lets assume we want to compile a program which is made from 
two modules, boot and body, where boot starts up in a way to suit a 
particular environment and then calls body. So when run

   boot --> body   (i.e. boot calls body)

Say we need the program to work in three environments: x86-16, x86-32 
and x86-64.

That could be done with the following four pieces of source code

   x16/boot.nasm
   x32/boot.nasm
   x64/boot.nasm
   body.c

The idea would be that body.c would be portable but that

   xN/boot.nasm

would be N-bit assembly code.

The config file that describes the code (call it Pbuild.cfg) would say 
things like

   x16/*  bits=16 cpu=x86
   x32/*  bits=32 cpu=x86
   x64/*  bits=64 cpu=x86

If body.c were to be completely portable it would need no such 
description because it had no restrictions.

A build of that lot would produce six object files which could be named

   x86-16/x16/boot.nasm.o
   x86_32/x32/boot.nasm.o
   x86_64/x64/boot.nasm.o

   x86_16/body.c.o
   x86_32/body.c.o
   x86_64/body.c.o

To form a complete app the relevant parts would be linked together but 
linking is another topic so I won't go in to it just now.

The idea is that all such object files would be built or rebuilt 
automatically, using the info in the config files to decide what to do, 
and using the dates and dependencies to limit the work done to the 
minimum needed.

That's how I see this working. Does it all make a bit more sense now?


-- 
James Harris

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

#3960

On 24/03/18 16:48, James Harris wrote:
>>> [...] That leads to many makefiles having to split the operations
>>> so you often see
>>>      make depend
>>>      make
>>> The second command uses the dependency files produced by the first. It
>>> would be better to have that stuff handled automatically.
>>     Arguably;  but that would require "make" to re-determine all the
>> dependencies.
> Sure. Is that bad?

	Well, it's less efficient [not really an issue, it isn't usually
"make" itself, as opposed to the commands it runs, that takes the time].
There is a much more serious problem in that you could finish up with a
never-ending make if the "make" process changes some files creating a
new list of things to do which change some files creating ....  I expect
there could be ways around that.

	If "make depend;  make" really bothers you, put a "make" at the
end of the commands run by "make depend"?  [Works on my computer, don't
know whether it's guaranteed.]

>>> 3. The make command is, if anything, too flexible for building
>>> programs, and that leads to some people writing crazy makefiles.
>>     I asked earlier what you meant by "flexible", and I'm still not
>> sure I understand your point. [...]
> A makefile can do almost anything you can do under your id,

	Well, yes.  So can lots of commands.  The moral is not to let
any code that you don't entirely trust* run on your computer with your
privileges.  Nothing special about "make".  [Not that I often have to
use external "makefile"s these days -- most of my software is installed
from the repositories.]

   * Or indeed, any code -- I assume you know Ken Thompson's 1984 ACM
     Turing Award lecture/paper on trust?  But I don't suppose many of
     us have gone to the lengths of re-compiling "make" from source
     using entirely hand-written tools, etc., etc.

>							      and some
> people who write makefiles should enter obfuscation contests. They
> could be even worse when written by a program.

	That hasn't really been my experience, so I'm still not entirely
clear what your problem is.

> Rather than that, sometimes, restrictions which enforce a dependable
> structure can be very welcome.

	I understand that in terms of what can be done [eg] inside a
programming language -- that adding feature after feature is not always
a Good Thing --, I'm less clear what commands you want to disallow in
a "makefile" [or near equivalent].  Other, of course, than the commands
you could equally allow/disallow in a restricted shell.

[...]
> To be clear of how I see this all fitting together, the user running
> the builds would have a config file (call it ~/.pbuild.cfg) which
> said things like> * to build 16-bit x86 code from .nasm sources ... [...]
> * to build 16-bit x86 code from .c sources ... [...]

	How does this differ [in an interesting way] from a target

   x86-16code: boot.nasm body.o
           ...
           ...

in a "makefile"?  You still seem to me to be re-inventing wheels.
Your new wheels may be just a little smoother than the old ones, at
least for your own purposes, but unless your new facility becomes
widespread this will be "private grief";  and there is nothing
stopping you writing your own "makefile"s in a way that conforms to
your ideals of using only a few [and transparent] commands.

-- 
Andy Walker,
Nottingham.

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

#3961

On 26/03/2018 19:42, Andy Walker wrote:
> On 24/03/18 16:48, James Harris wrote:

...

> 	How does this differ [in an interesting way] from a target
> 
>     x86-16code: boot.nasm body.o
>             ...
>             ...
> 
> in a "makefile"?  You still seem to me to be re-inventing wheels.
> Your new wheels may be just a little smoother than the old ones, at
> least for your own purposes, but unless your new facility becomes
> widespread this will be "private grief";  and there is nothing
> stopping you writing your own "makefile"s in a way that conforms to
> your ideals of using only a few [and transparent] commands.

Sorry, Andy, I don't mean to be vague but it's hard to reply to the 
things you asked me in your post because I can see there are some things 
you've not understood and yet I don't think I can explain it any better. 
If I write it and if I release it it might make a wee bit more sense to 
see it in operation.


-- 
James Harris

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

#3951

James Harris <james.harris.1@gmail.com> writes:
>> [...]
>>> The idea is that one config file would say what restrictions or
>>> limitations source files had (e.g. word size, endianness assumptions,
>>> required hardware, required libraries etc)
>>
>> 	If your code really has limitations because of such features
>> [eg, won't work on 16-bit or big-endian machines], then there's not
>> much more to be said, except "caveat emptor". 
>
> Even assembly code...?
>
> Take another example, an IRQ handler. Even if written in a HLL it
> would be specific to a certain CPU. That doesn't mean it lacks
> portability it should have.


Here is how you write IRQ handlers:

    #include <sys/time.h>
    #include <stdio.h>
    #include <signal.h>
    #include <unistd.h>

    #define unused(x) ((void)x)
    int irq_processed=0;
    void irq_handler(int signal){
        unused(signal);
        irq_processed=1;}
    int main(){
        int count=3;
        struct itimerval timer={ /* interval = */ { 3,0 },
                                 /* delay    = */ { 1,0 }};
        signal(SIGALRM,irq_handler);
        setitimer(ITIMER_REAL,&timer,0);
        while(count>0){
            while(0==irq_processed){
                sleep(1);}
            printf("!");
            fflush(stdout);
            irq_processed=0;
            count--;}
        printf("\n");
        fflush(stdout);
        return 0;}

This works on all processors.

(And if you're amongst the 0.00000001% of the programmers in the world
who write the linux kernel, then you know what I mean).

        
> Hopefully the above explains some of the reasons why I started looking
> at a custom system.

Nothing wrong with that, but the yet another make system syndrome.

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

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

#3943

Andy Walker <anw@cuboid.co.uk> writes:

> On 21/03/18 06:03, James Harris wrote:
>>					That's not good. It would be
>> better if we could specify - and limit - the commands a makefile was
>> able to run.
>
> 	You can't.  Not sensibly.  There is no point to a makefile
> that cannot do the most obvious things such as compiling, creating
> files and moving them around.  You can run "make" in a sandbox if
> you like, but that's nothing to do with "make", but rather with the
> facilities you get with a security-conscious OS.

Actually, as I demonstrated, you can, easily and sensibly.
Just set the SHELL to your own command interpreter.

While (most versions of) MS-Windows don't have a standard POSIX shell
and command set, writing a POSIX C program that can be compiled and run
equivalently on unix and MS-Windows seems to be rather feasible.

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

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

#3942

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

> On 19/03/2018 13:38, Andy Walker wrote:
>> On 17/03/18 18:32, bartc wrote:
>
> ...
>
>>> I need certain information, and the makefile fanatics want to do
>>> their utmost to hide it from me.
>>
>> 	Blame fanaticism rather than "make".
>
> While I agree with that as a basic point isn't there also a case to
> say that make is too flexible and allows users to do crazy things?

Universal Turing Machines are universal.
Programmers are crazy people doing crazy things.
Programmers are not users.
Users use Turing Machines, not Universal Turing Machines.
Users don't do crazy things.
Crazy things are done to users.
Users are fucked.


> When we think about it, flexibility always sounds appealing to us
> individually as it allows us to do things which we could not easily do
> otherwise. But flexibility is not so good when others overuse it and
> then expect us to work with their complex and outre solutions. That's
> why I would say that too much flexibility can be a bad thing.

Then drop programming, become a user.
Get yourself an iPhone and use facebook!


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

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

#3933

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

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



-- 
bartc

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

#3938

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

> In the 80s and 90s, I would distribute apps on floppy disk. [...]
> The users were non-technical and wouldn't have any idea what a
> makefile was (neither did I at the time).

	Nor should they have;  nor have you explained the relevance.  I
installed Unix [in various flavours] and a large number of applications
on a variety of computers between 1977 and the present equally without
using or being required to understand the concept of a "makefile".  I
did in fact understand that, and wrote and used my own, and used those
of other people when installing from source.  But naive users aren't
expected to do that [and probably have little use for Algol compilers
and such-like anyway].

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

	When you download to a smart-phone, Apple/Samsung/... know what
environment you are downloading to, and it is reasonable for them to
have a sufficient collection of pre-built binaries for the environments
that they support, including knowing where to put them.  The same applies
to tablets, to MicroSoft in respect of Windows machines, and to other
major suppliers of software and hardware.  It equally applies to the
"repository" software for Linux [inc "gcc", since that seems to have
been exercising you].  No "make" or "makefile" in sight.

	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.  If, as most Linux people are, he/she is generous of spirit, you
can instead download the source and compile it yourself.  You will find
this much easier if part of the source is a "makefile".  Not impossible
without;  but you are likely to have to read many of the files, and very
possibly edit them to reflect things like word-length, location of system
commands, and all the other details that may differ between your computer
and anyone else's.

	The problems are particularly acute for Linux, not because of any
defect, but because [unlike offerings from MS, Apple and Samsung] it runs
virtually unchanged between legacy computers [such as the PDP 11 -- yes,
40+ years old], some of the smallest modern micros, and most of the
world's biggest and most powerful supercomputers.

-- 
Andy Walker,
Nottingham.

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

#3940

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.

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

>      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. There seem to be plenty of viruses around especially for the 
former; I don't recall having to build /those/ from source!

  If, as most Linux people are, he/she is generous of spirit, you
> can instead download the source and compile it yourself.  You will find
> this much easier if part of the source is a "makefile".

For a few years I've been going to the considerable trouble of making 
certain kinds of programs (compilers, interpreters, assemblers) 
available as a single C source file that would be as easy to build as:

     gcc hello.c -ohello.exe

And this largely worked (except that the source was specific to 32- or 
64-bit, and and some features might be restricted if the source I gave 
out was OS-neutral).

THIS was the simplest possible way of building from source. Except some 
people (who probably didn't like me nor my work) still complained that 
it was too hard.

Perhaps they are so used to typing 'make' that they've forgotten how to 
compile a file by hand.

If all that goes on inside a configure/make system is likened to 
installing a self-assembly kitchen, then I've reduced to process to 
hammering in  a single nail. But apparently even that is too hard.

I've since stopped creating such distributions as it's quite a bit of 
work. (My apps are not written in C, they are in multiple files not one, 
and I have to run special collating programs to create the 'amalgamated' 
file, an error prone process that takes a lot of checking.)

Because I don't think anyone bothers with them apart from that 
unfriendly bit of feedback.

Also, if you distribute anything in C, then someone can choose to ramp 
up the warnings on their C compiler so that it spews out loads of 
output. Another black mark against your program.

So at the moment I don't have any means of distributing programs as 
source. (I supply binary .exe files as the simplest way of doing it; but 
someone still has to get them past their AV and out of their browser 
onto their machine, which is no longer a trivial procedure.)


-- 
bartc

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

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

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

csiph-web