Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.misc > #3851 > unrolled thread
| Started by | James Harris <james.harris.1@gmail.com> |
|---|---|
| First post | 2018-03-01 14:40 +0000 |
| Last post | 2018-03-14 13:39 +0100 |
| Articles | 10 on this page of 110 — 11 participants |
Back to article view | Back to comp.lang.misc
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 6 of 6 — ← Prev page 1 2 3 4 5 [6]
| From | James Harris <james.harris.1@gmail.com> |
|---|---|
| Date | 2018-03-15 20:37 +0000 |
| Message-ID | <p8eli7$2c4$1@dont-email.me> |
| In reply to | #3910 |
On 15/03/2018 10:29, Rod Pemberton wrote:
> 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?
No, because the code could be in any language and the build system
wouldn't know how to interpret all languages.
>
> 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?
Yes, I have in mind that the coder of the source files would write the
configs to describe those source files. I haven't worked out the
specifics yet but to make an example, a config file could look like this
drivers/*.nasm: bits=32 cpu=386-pmode
system/*: bits=32..
The first line says that all the .nasm files in the drivers/ folder are
written for 32-bit object code and for a certain CPU mode.
The second line would say that the files in system/ can work with 32-bit
or greater word sizes. (The .. here means "or greater".)
The idea is as follows.
1. If the build system were told to make 32-bit PMode objects then it
would build files matching both of these.
drivers/*.nasm
system/*
2. But if it were told to make 32-bit Arm objects then it would create
them only from
system/*
(There would presumably be another folder which supplied the relevant
Arm-system drivers.)
>
>> * any other limitations of each source file
>
> Wouldn't limitations go against the portable code concept? ;-)
You put a smiley so I guess you are joking, but one limitation might be
that portable source code would need a certain minimum integer size such
as ints which have to be at least 32 bits wide (but could be larger). An
alternative limitation could be that the code would work on a certain
architecture of machine - such as an IBM AT compatible.
>
>> 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? ...
I don't intend to emit a makefile. :-)
The idea is that the build system would invoke compilers and other
programs as needed.
>
>> 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.
I was thinking more about cross compiling: one platform having compilers
for different targets.
>
>> 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
The great thing about having config files is the person who writes the
source can organise it as he or she chooses. For example, a config file
could specify each source file individually.
drivers/kb_16.nasm: bits=16
drivers/kb_32.nasm: bits=32
drivers/kb_64.nasm: bits=64
drivers/kbc_16.nasm: bits=16
drivers/kbc_32.nasm: bits=32
drivers/kbc_64.nasm: bits=64
But that would be a pain so the programmer could choose to organise the
source tree in a better way, making the config file simpler.
drivers_x16/*: bits=16
drivers_x32/*: bits=32
drivers_x64/*: bits=64
Then drivers_x16 would include all the 16-bit drivers. And so on. The
programmer could choose how to lay out the source tree.
>
>> 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? ...
The user would run one command but that command would run multiple
compile commands...!
>
> 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:
Goodness! That's all a bit elaborate. Tomorrow the world, eh! In fact,
the mechanics of how it would be run aren't important just now. I'm only
looking at a way to control what compile commands are run.
>
> 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.
You maybe have something more elaborate in mind. I am thinking only that
the user will run one command, call it CCC, and the CCC program will
work out which other commands to run. For example, if "sym" were to be a
folder containing source code, the command might be
CCC sym
What CCC would do is
1. Look for a config file in sym which tells it what each of the source
files in sym is capable of.
2. Iterate over the source files in sym. For each one:
2a. Work out all the different object files we can derive from it[*].
2b. For each one, if it exists and is up to date then do nothing.
2c. For each which is missing or is not up to date ... build it.
[*] Working out what object files we can derive from each source file is
something I still have to come up with a mechanism for but it will
probably be down to per-user config files something like the following.
Imagine the following is (a simplified version of) a config file in the
user's directory
target x32: bits=32
cc -m32 <src> -o <obj>
target x64: bits=64
cc -m64 <src> -o <obj>
target arm_32: bits=32
gcc-arm-linux-gnueabihf -m32 <src> -o <obj>
The idea is that the CCC program mentioned earlier would see that a
certain source file can be compiled for the x64 target and then run the
target x64 command on that source file, and similar for other options.
To be clear, there are two types of config files. One is to be supplied
with the source files and describes their characteristics (such as "this
file will work with word sizes of 32-bits or more"). The other is
written by the person running the builds and says "to compile for x86-64
this is the recipe". (As with make, the indented commands are recipes
and there can be multiple commands there.)
Does that make more sense now?
>
>> 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 could be an option. But I wouldn't want to compile *all* C and
assembly code to byte code (!) so other options are also needed.
>
>> 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
You have in mind some things which are different from what I intend.
--
James Harris
[toc] | [prev] | [next] | [standalone]
| From | Rod Pemberton <NoEmail@trraxvfeqa.prg> |
|---|---|
| Date | 2018-03-17 11:51 -0400 |
| Message-ID | <p8jddr$vo7$1@gioia.aioe.org> |
| In reply to | #3913 |
On Thu, 15 Mar 2018 20:37:24 +0000 James Harris <james.harris.1@gmail.com> wrote: > On 15/03/2018 10:29, Rod Pemberton wrote: > > 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: > >> * what CPU modes or architectures each requires > > > > Should the code (or coder) decide this? What if the mode or > > architecture isn't available? > > Yes, I have in mind that the coder of the source files would write > the configs to describe those source files. How do you prevent mismatch between code and configs? I.e., parsing code to generate the config would seem to be more reliable, IMO. However, you've dismissed that as unreasonable because the build tool chain is unfamiliar with programming languages. In which case, you'd need a custom tool to parse for each language. > I haven't worked out the > specifics yet but to make an example, a config file could look like > this > > drivers/*.nasm: bits=32 cpu=386-pmode > system/*: bits=32.. > > The first line says that all the .nasm files in the drivers/ folder > are written for 32-bit object code and for a certain CPU mode. > > The second line would say that the files in system/ can work with > 32-bit or greater word sizes. (The .. here means "or greater".) Since mismatch, due to coding mistakes, is a real possibility here, do you have any sanity checks for when say the programmer cuts-and-pastes - horrors! - and forgets to change 32 to 64? (Don't forget that people are screw-ups and also get sleepy and drunk etc ... I'm not saying be paternalistic, as I believe in total-user-control, but sometimes you need to make things more reliable or automated.) > >> * any other limitations of each source file > > > > Wouldn't limitations go against the portable code concept? ;-) > > You put a smiley Well, it's a winking smiley. > but one limitation might > be that portable source code would need a certain minimum integer > size such as ints which have to be at least 32 bits wide (but could > be larger). An alternative limitation could be that the code would > work on a certain architecture of machine - such as an IBM AT > compatible. Well, today, x86 and ARM are important, and there are a couple of relatively new popular micro-controller platforms, Arduino (AVR) and Raspberry Pi (ARM), and the old 8051. But, you may want compile a cross-reference. There is a good Wikipedia article on the processor word size, which I probably mentioned before. https://en.wikipedia.org/wiki/Word_(computer_architecture) Also, this came up on Hackaday: https://jaycarlson.net/microcontrollers/ > I don't intend to emit a makefile. :-) > > The idea is that the build system would invoke compilers and other > programs as needed. Why would I suspect that may be more complicated than emitting a makefile? > I was thinking more about cross compiling: one platform having > compilers for different targets. Why? We've got cloud-computing. That doesn't mean every computer in the cloud must be the same architecture. To answer my own "Why?", there are some situations where cross-compiling might be preferred, e.g., producing code for an old 8-bit. > The great thing about having config files is the person who writes > the source can organise it as he or she chooses. For example, a > config file could specify each source file individually. > > drivers/kb_16.nasm: bits=16 > drivers/kb_32.nasm: bits=32 > drivers/kb_64.nasm: bits=64 > drivers/kbc_16.nasm: bits=16 > drivers/kbc_32.nasm: bits=32 > drivers/kbc_64.nasm: bits=64 > > But that would be a pain so the programmer could choose to organise > the source tree in a better way, making the config file simpler. > > drivers_x16/*: bits=16 > drivers_x32/*: bits=32 > drivers_x64/*: bits=64 > > Then drivers_x16 would include all the 16-bit drivers. And so on. The > programmer could choose how to lay out the source tree. No offense, but once you include RegEx's (or Kleene algebra) with the ability to specify programs such as compilers or assemblers, and sequence ordering of some sort, e.g., by line, then it appears to me that you're recreating the functionality of make files. Wikipedia refers to this as "build automation". The only differences I recall ATM are a) you want to support multiple language and b) you want to be able to use permanent identifiers. https://en.wikipedia.org/wiki/Kleene_algebra https://en.wikipedia.org/wiki/Makefile https://en.wikipedia.org/wiki/Build_automation > > 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. > > You maybe have something more elaborate in mind. I am thinking only > that the user will run one command, call it CCC, and the CCC program > will work out which other commands to run. For example, if "sym" were > to be a folder containing source code, the command might be > > CCC sym > Ok. So, what is wrong with file extensions, e.g., .c .cpp .nasm etc, to decide which compiler or assembler to use? This works. > What CCC would do is > > 1. Look for a config file in sym which tells it what each of the > source files in sym is capable of. If the extension specifies the compiler to run, wouldn't this suffice much of the time? > 2. Iterate over the source files in sym. For each one: > > 2a. Work out all the different object files we can derive from it[*]. > > 2b. For each one, if it exists and is up to date then do nothing. > > 2c. For each which is missing or is not up to date ... build it. > > [*] Working out what object files we can derive from each source file > is something I still have to come up with a mechanism for Do all these languages have the ability to have multi-line or block comment sections? ... If so, you could place a specification within a comment block near the start of the file. Then, you just need some code to detect and extract the specification. This would save you from needing to actually parse the code. Obviously, you probably want something unique to act as a flag or magic value or sentinel to key off of to find the specification. And, you may need to specify it is located within the first 100 or so lines of the code, etc., e.g., for C, C++, NASM: /* */ /*<James' build-tool specification start> */ /* source C */ /* build-target 32-bit */ /* output COFF */ /* </James' build-tool specification end> */ /* */ // //<James' build-tool specification start> // source C++ // build-target 64-bit // output PE //</James' build-tool specification end> // ; ;<James' build-tool specification start> ; source NASM ; build-target 16-bit ; output DOS .EXE ;</James' build-tool specification end> ; > [*] Working out what object files we can derive from each source file > is something I still have to come up with a mechanism for Oh, so, a key issue really is the building of multiple targets. Why do they need to all be built at once? Can't you build one after another? If so, then you can clean, set new target, build, save output files, repeat. > but it will > probably be down to per-user config files something like the > following. See my within the comment block suggestion above. > Imagine the following is (a simplified version of) a > config file in the user's directory > > target x32: bits=32 > cc -m32 <src> -o <obj> > > target x64: bits=64 > cc -m64 <src> -o <obj> > > target arm_32: bits=32 > gcc-arm-linux-gnueabihf -m32 <src> -o <obj> I think you could put all that and plenty more in a comment-block specification. > >> 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 could be an option. But I wouldn't want to compile *all* C and > assembly code to byte code (!) so other options are also needed. Just what do you have against byte code? You know, nobody likes a byte-code hater ... Please, stop being divisive and discriminatory. ;-) LOL. Rod Pemberton -- feedback loop: Russian aggression -> World complains -> Russian paranoia -> Russian threats -> repeat
[toc] | [prev] | [next] | [standalone]
| From | James Harris <james.harris.1@gmail.com> |
|---|---|
| Date | 2018-03-20 06:31 +0000 |
| Message-ID | <p8q9rp$7gn$1@dont-email.me> |
| In reply to | #3920 |
On 17/03/2018 15:51, Rod Pemberton wrote:
> On Thu, 15 Mar 2018 20:37:24 +0000
> James Harris <james.harris.1@gmail.com> wrote:
>
>> On 15/03/2018 10:29, Rod Pemberton wrote:
>>> 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:
>
>>>> * what CPU modes or architectures each requires
>>>
>>> Should the code (or coder) decide this? What if the mode or
>>> architecture isn't available?
>>
>> Yes, I have in mind that the coder of the source files would write
>> the configs to describe those source files.
>
> How do you prevent mismatch between code and configs? I.e., parsing
> code to generate the config would seem to be more reliable, IMO.
> However, you've dismissed that as unreasonable because the build
> tool chain is unfamiliar with programming languages. In which case,
> you'd need a custom tool to parse for each language.
Yes, it would be user responsibility to ensure that the configs were
correct for the code. Frankly, even if code scanners were to be written
for every language and dialect they could not determine everything that
a human knows about code limits so it's probably not possible to
automate the specification.
>
>> I haven't worked out the
>> specifics yet but to make an example, a config file could look like
>> this
>>
>> drivers/*.nasm: bits=32 cpu=386-pmode
>> system/*: bits=32..
>>
>> The first line says that all the .nasm files in the drivers/ folder
>> are written for 32-bit object code and for a certain CPU mode.
>>
>> The second line would say that the files in system/ can work with
>> 32-bit or greater word sizes. (The .. here means "or greater".)
>
> Since mismatch, due to coding mistakes, is a real possibility here, do
> you have any sanity checks for when say the programmer cuts-and-pastes -
> horrors! - and forgets to change 32 to 64? (Don't forget that people
> are screw-ups and also get sleepy and drunk etc ... I'm not saying be
> paternalistic, as I believe in total-user-control, but sometimes you
> need to make things more reliable or automated.)
As above, I don't think it's possible to automate this reliably.
>
>>>> * any other limitations of each source file
>>>
>>> Wouldn't limitations go against the portable code concept? ;-)
>>
>> You put a smiley
>
> Well, it's a winking smiley.
>
>> but one limitation might
>> be that portable source code would need a certain minimum integer
>> size such as ints which have to be at least 32 bits wide (but could
>> be larger). An alternative limitation could be that the code would
>> work on a certain architecture of machine - such as an IBM AT
>> compatible.
>
> Well, today, x86 and ARM are important, and there are a couple of
> relatively new popular micro-controller platforms, Arduino (AVR) and
> Raspberry Pi (ARM), and the old 8051. But, you may want compile a
> cross-reference. There is a good Wikipedia article on the processor
> word size, which I probably mentioned before.
>
> https://en.wikipedia.org/wiki/Word_(computer_architecture)
>
> Also, this came up on Hackaday:
> https://jaycarlson.net/microcontrollers/
>
>> I don't intend to emit a makefile. :-)
>>
>> The idea is that the build system would invoke compilers and other
>> programs as needed.
>
> Why would I suspect that may be more complicated than emitting a
> makefile?
It probably would. But it might be easier in the long run to have a
custom process. It's a critical-mass issue. There comes a point where
the effort of working with existing tools becomes so great that it
becomes better to make a new tool.
>
>> I was thinking more about cross compiling: one platform having
>> compilers for different targets.
>
> Why? We've got cloud-computing. That doesn't mean every computer
> in the cloud must be the same architecture.
>
> To answer my own "Why?", there are some situations where
> cross-compiling might be preferred, e.g., producing code for an old
> 8-bit.
AISI compilers and assemblers are standard programs which read input and
produce output. There's no a priori requirement for them to produce
output for the type of machine they are running on. None at all. A
compiler which emits code for a 68040, for example, could run on a MIPS
CPU or any other turing machine. I don't understand the predominance of
the idea that compilers must produce output for the machines they run on.
>
>> The great thing about having config files is the person who writes
>> the source can organise it as he or she chooses. For example, a
>> config file could specify each source file individually.
>>
>> drivers/kb_16.nasm: bits=16
>> drivers/kb_32.nasm: bits=32
>> drivers/kb_64.nasm: bits=64
>> drivers/kbc_16.nasm: bits=16
>> drivers/kbc_32.nasm: bits=32
>> drivers/kbc_64.nasm: bits=64
>>
>> But that would be a pain so the programmer could choose to organise
>> the source tree in a better way, making the config file simpler.
>>
>> drivers_x16/*: bits=16
>> drivers_x32/*: bits=32
>> drivers_x64/*: bits=64
>>
>> Then drivers_x16 would include all the 16-bit drivers. And so on. The
>> programmer could choose how to lay out the source tree.
>
> No offense, but once you include RegEx's (or Kleene algebra) with the
> ability to specify programs such as compilers or assemblers, and
> sequence ordering of some sort, e.g., by line, then it appears to me
> that you're recreating the functionality of make files. Wikipedia
> refers to this as "build automation". The only differences I recall
> ATM are a) you want to support multiple language and b) you want to be
> able to use permanent identifiers.
>
> https://en.wikipedia.org/wiki/Kleene_algebra
> https://en.wikipedia.org/wiki/Makefile
> https://en.wikipedia.org/wiki/Build_automation
That last link was very useful, thanks. By showing there are many
build-automation systems it suggests that others have found that no one
solution is the last word on the subject. And having looked at some of
the more promising ones and seen that they each have their own faults,
it's reassuring in two ways: first that solutions are not simple and
second that it can be worth writing a custom one.
>
>>> 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.
>>
>> You maybe have something more elaborate in mind. I am thinking only
>> that the user will run one command, call it CCC, and the CCC program
>> will work out which other commands to run. For example, if "sym" were
>> to be a folder containing source code, the command might be
>>
>> CCC sym
>>
>
> Ok. So, what is wrong with file extensions, e.g., .c .cpp .nasm etc, to
> decide which compiler or assembler to use? This works.
There's nothing wrong with using file extensions. Within sym there would
be source files with extensions indicating the type of the file. And the
file type would be combined with the desired targets (CPU, mode, calling
convention, etc) to determine the commands to run. Examples below.
>
>> What CCC would do is
>>
>> 1. Look for a config file in sym which tells it what each of the
>> source files in sym is capable of.
>
> If the extension specifies the compiler to run, wouldn't this suffice
> much of the time?
Not really. Let me give you an example.
Say we have a C file which is to be compiled and it can become an object
file for 16-bit or 32-bit x86. The compile command for 32-bit
"$(target)" output might be something like
cc -m32 -c $(src) -o $(target)
By contrast, the 'recipe' for 16-bit output might be
cc -c -m16 $(src) -o /dev/null
cc -E -m16 --sysroot=/usr/lib/bcc $(src) \
| /usr/lib/bcc/unproto \
| /usr/lib/bcc/bcc-cc1 -0 \
| /usr/bin/as86 -u -w -0 -n $(src) -o $(target)
Basically, the command to be run would depend on the source file type
/and/ the target file type. The full command including all options would
depend on a lot more, but hopefully the above shows the idea.
>
>> 2. Iterate over the source files in sym. For each one:
>>
>> 2a. Work out all the different object files we can derive from it[*].
>>
>> 2b. For each one, if it exists and is up to date then do nothing.
>>
>> 2c. For each which is missing or is not up to date ... build it.
>>
>> [*] Working out what object files we can derive from each source file
>> is something I still have to come up with a mechanism for
>
> Do all these languages have the ability to have multi-line or block
> comment sections? ... If so, you could place a specification within a
> comment block near the start of the file. Then, you just need some
> code to detect and extract the specification. This would save you from
> needing to actually parse the code.
>
> Obviously, you probably want something unique to act as a flag or magic
> value or sentinel to key off of to find the specification. And, you may
> need to specify it is located within the first 100 or so lines of the
> code, etc., e.g., for C, C++, NASM:
>
> /* */
> /*<James' build-tool specification start> */
> /* source C */
> /* build-target 32-bit */
> /* output COFF */
> /* </James' build-tool specification end> */
> /* */
>
> //
> //<James' build-tool specification start>
> // source C++
> // build-target 64-bit
> // output PE
> //</James' build-tool specification end>
> //
>
> ;
> ;<James' build-tool specification start>
> ; source NASM
> ; build-target 16-bit
> ; output DOS .EXE
> ;</James' build-tool specification end>
> ;
For lots of reasons I am not sure why someone would do that. For
example, if you had a folder with 20 files which all had the same
specification why would you change each one? Wouldn't it be easier to
just say that all files in that folder had a certain specification?
>
>> [*] Working out what object files we can derive from each source file
>> is something I still have to come up with a mechanism for
>
> Oh, so, a key issue really is the building of multiple targets.
Yes, very much so.
>
> Why do they need to all be built at once? Can't you build one after
> another? If so, then you can clean, set new target, build, save
> output files, repeat.
They don't, but building all at once could be the default. What I have
in mind is to allow the set of targets to be restricted as needed. For
example, if the build command is CCC, as before, then
CCC folder
would build all possible targets for all source files in that folder. But
CCC --cconv syscall --and --cpu arm folder
would only build targets which were for Arm CPUs and used the syscall
calling convention. (That's not a defined syntax, just a possible way of
specifying the targets.)
--
James Harris
[toc] | [prev] | [next] | [standalone]
| From | Rod Pemberton <NoEmail@trraxvfeqa.prg> |
|---|---|
| Date | 2018-03-20 17:14 -0400 |
| Message-ID | <p8rtf9$1gsu$2@gioia.aioe.org> |
| In reply to | #3928 |
On Tue, 20 Mar 2018 06:31:18 +0000 James Harris <james.harris.1@gmail.com> wrote: > On 17/03/2018 15:51, Rod Pemberton wrote: > > On Thu, 15 Mar 2018 20:37:24 +0000 > > James Harris <james.harris.1@gmail.com> wrote: > > > >> On 15/03/2018 10:29, Rod Pemberton wrote: > >>> 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: > >>>> * what CPU modes or architectures each requires > >>> > >>> Should the code (or coder) decide this? What if the mode or > >>> architecture isn't available? > >> > >> Yes, I have in mind that the coder of the source files would write > >> the configs to describe those source files. > > > > How do you prevent mismatch between code and configs? I.e., parsing > > code to generate the config would seem to be more reliable, IMO. > > However, you've dismissed that as unreasonable because the build > > tool chain is unfamiliar with programming languages. In which case, > > you'd need a custom tool to parse for each language. > > Yes, it would be user responsibility to ensure that the configs were > correct for the code. Frankly, even if code scanners were to be > written for every language and dialect they could not determine > everything that a human knows about code limits so it's probably not > possible to automate the specification. > I generally, other than 32-bit, 16-bit, etc, don't know anything about code limits. I let the code get the information from the compiler, if I need to know. Do you seriously memorize all the output that Enquire.c can produce? Do you do so for multiple platforms? Each C compiler can a completely different set of values, even on the same machine. At some point, you'll get all that info confused. https://homepages.cwi.nl/~steven/enquire.html > >> I don't intend to emit a makefile. :-) > >> > >> The idea is that the build system would invoke compilers and other > >> programs as needed. > > > > Why would I suspect that may be more complicated than emitting a > > makefile? > > It probably would. But it might be easier in the long run to have a > custom process. It's a critical-mass issue. There comes a point where > the effort of working with existing tools becomes so great that it > becomes better to make a new tool. > Can I take it that you believe we've reached or exceeded the critical-mass event as arbitrarily decided upon by you? ... If so, what pushed you over the edge? It clearly wasn't any of Banksy's irreverent artwork/graffiti. > >> I was thinking more about cross compiling: one platform having > >> compilers for different targets. > > > > Why? We've got cloud-computing. That doesn't mean every computer > > in the cloud must be the same architecture. > > > > To answer my own "Why?", there are some situations where > > cross-compiling might be preferred, e.g., producing code for an old > > 8-bit. > > AISI compilers and assemblers are standard programs which read input > and produce output. There's no a priori requirement for them to > produce output for the type of machine they are running on. None at > all. > A compiler which emits code for a 68040, for example, could run > on a MIPS CPU or any other turing machine. True. But, this is usually because the compiler has been ported to another architecture, e.g., the MIPS CPU etc, /after/ already being made to work for the original host microprocessor and operating system, which the compiler on a different platform is now cross-compiling for, e.g., the 68040. > I don't understand the predominance of the idea that compilers must > produce output for the machines they run on. I think you'd agree that the x86 has numerous processor modes: RM16, VM16/E0/E1, PM16, PM32, CM16, CM32, PM64, and numerous operating systems: MS-DOS, PC-DOS, IBM DOS, DR-DOS, IBM OS/2, Windows 3.1, Windows NT, Windows 98, Windows SE, Windows ME, Windows Vista, Windows 7, Windows 8, Windows 10, Linux and various Mac OSes. And, there are even more environments than that, as code could be produced specifically for various DPMI hosts, VCPI hosts, EMS hosts, XMS hosts, and DOS Extenders used with DOS. So, a native compiler must generate code for the specific processor mode and the specific host operating system or environment. This must be working /before/ producing a cross-compiler. I.e., you must produce output for the machine the code runs on first, in order to make sure it works, before transferring the tool chain to another architecture, in order to cross-compile. Do you agree with that sequence of events? > That last link was very useful, thanks. By showing there are many > build-automation systems it suggests that others have found that no > one solution is the last word on the subject. And having looked at > some of the more promising ones and seen that they each have their > own faults, it's reassuring in two ways: first that solutions are not > simple and second that it can be worth writing a custom one. > Are you familiar with psychology? If not, look up confirmation bias. It's a type of cognitive bias. There are 188 known cognitive biases. These are types of defective decision-making or faulty logic built into the human mind. Some are more serious than others. https://en.wikipedia.org/wiki/Confirmation_bias I.e., you could've just as easily come to the conclusion that the existence of many build-automation systems suggests that the concept of build-automation is not an effective solution in general. You also could've concluded that since "each have their own faults," and that since there are many systems, that there is no perfect solution to be found. In other words, your conclusions seem to be arbitrary, i.e., you're interested in this project, so you've characterized it in the best possible light, while disregarding the possible negatives. > >> What CCC would do is > >> > >> 1. Look for a config file in sym which tells it what each of the > >> source files in sym is capable of. > > > > If the extension specifies the compiler to run, wouldn't this > > suffice much of the time? > > Not really. Let me give you an example. > > Say we have a C file which is to be compiled and it can become an > object file for 16-bit or 32-bit x86. The compile command for 32-bit > "$(target)" output might be something like > > cc -m32 -c $(src) -o $(target) > > By contrast, the 'recipe' for 16-bit output might be > > cc -c -m16 $(src) -o /dev/null > cc -E -m16 --sysroot=/usr/lib/bcc $(src) \ > | /usr/lib/bcc/unproto \ > | /usr/lib/bcc/bcc-cc1 -0 \ > | /usr/bin/as86 -u -w -0 -n $(src) -o $(target) > If they're both for x86, I'd think they'd be far more similar than that. I.e., I'd expect both similar to the first line. If cross-compiling or building a standalone environment, I'd suspect something more like the later. > Basically, the command to be run would depend on the source file type > /and/ the target file type. The full command including all options > would depend on a lot more, but hopefully the above shows the idea. I would think that you could produce links or files with different names, that are designed to execute the compiler in different ways. E.g., (normal) cc -m32 -c $(src) -o $(target) (cross) cc-x -m32 -c $(src) -o $(target) Simply calling cc-x instead of cc, would do all the extra stuff. Of course, this would depend on producing a script or batch file named cc-x. You'd probably need something a like Linux shell, bash, on targets which don't support it. Or, you could use a makefile with make, ISTM. > >> 2. Iterate over the source files in sym. For each one: > >> > >> 2a. Work out all the different object files we can derive from > >> it[*]. > >> > >> 2b. For each one, if it exists and is up to date then do nothing. > >> > >> 2c. For each which is missing or is not up to date ... build it. > >> > >> [*] Working out what object files we can derive from each source > >> file is something I still have to come up with a mechanism for > > > > Do all these languages have the ability to have multi-line or block > > comment sections? ... If so, you could place a specification > > within a comment block near the start of the file. Then, you just > > need some code to detect and extract the specification. This would > > save you from needing to actually parse the code. > > > > Obviously, you probably want something unique to act as a flag or > > magic value or sentinel to key off of to find the specification. > > And, you may need to specify it is located within the first 100 or > > so lines of the code, etc., e.g., for C, C++, NASM: > > > > /* */ > > /*<James' build-tool specification start> */ > > /* source C */ > > /* build-target 32-bit */ > > /* output COFF */ > > /* </James' build-tool specification end> */ > > /* */ > > > > // > > //<James' build-tool specification start> > > // source C++ > > // build-target 64-bit > > // output PE > > //</James' build-tool specification end> > > // > > > > ; > > ;<James' build-tool specification start> > > ; source NASM > > ; build-target 16-bit > > ; output DOS .EXE > > ;</James' build-tool specification end> > > ; > > For lots of reasons I am not sure why someone would do that. To avoid doing 2a: > >> 2a. Work out all the different object files we can derive from > >> it[*]. The spec tells you "all the different object files we can derive from it," upfront, or, it could, if you so wish. > For > example, if you had a folder with 20 files which all had the same > specification why would you change each one? Wouldn't it be easier to > just say that all files in that folder had a certain specification? > If that's the case "that all files in that folder had a certain specification," couldn't you assume that the first file has the correct spec for the entire directory? If the first is deleted or renamed, another file, with the same specification, would be first. Or, you could just create a single file for the entire directory, which is typically called a makefile or build script. > > Why do they need to all be built at once? Can't you build one after > > another? If so, then you can clean, set new target, build, save > > output files, repeat. > > They don't, but building all at once could be the default. Without cloud computing or a compute farm of servers, I don't see how that could be the case. Well, I guess they could compile on different cores in parallel on the same machine, but that adds extra complexity as the host OS must support it. What if someone is compiling on a single-core machine or single-thread operating system? You simply can't compile all at once by default. ... > What I > have in mind is to allow the set of targets to be restricted as > needed. For example, if the build command is CCC, as before, then > > CCC folder > > would build all possible targets for all source files in that folder. Yup, that should be easy to do with the parallel processing available with cloud computing, especially if all the original host architectures are available to build with. I doubt they'd have something as old as a PDP-7 in their farm, but they might have a Cray or two ... Of course, you'd expect most of these farms to be x86 or ARM. > But > > CCC --cconv syscall --and --cpu arm folder > > would only build targets which were for Arm CPUs and used the syscall > calling convention. (That's not a defined syntax, just a possible way > of specifying the targets.) If you can compile one in the cloud, you can compile them all. (*) (*) I don't know if that's true, but it should be. There is no reason it couldn't be. It only takes someone with the money and vision. Rod Pemberton -- feedback loop: Russian aggression -> World complains -> Russian paranoia -> Russian threats -> repeat
[toc] | [prev] | [next] | [standalone]
| From | James Harris <james.harris.1@gmail.com> |
|---|---|
| Date | 2018-03-21 07:10 +0000 |
| Message-ID | <p8t0hl$npf$1@dont-email.me> |
| In reply to | #3934 |
On 20/03/2018 21:14, Rod Pemberton wrote: > On Tue, 20 Mar 2018 06:31:18 +0000 > James Harris <james.harris.1@gmail.com> wrote: > >> On 17/03/2018 15:51, Rod Pemberton wrote: >>> On Thu, 15 Mar 2018 20:37:24 +0000 >>> James Harris <james.harris.1@gmail.com> wrote: >>> >>>> On 15/03/2018 10:29, Rod Pemberton wrote: >>>>> 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: > >>>>>> * what CPU modes or architectures each requires >>>>> >>>>> Should the code (or coder) decide this? What if the mode or >>>>> architecture isn't available? >>>> >>>> Yes, I have in mind that the coder of the source files would write >>>> the configs to describe those source files. >>> >>> How do you prevent mismatch between code and configs? I.e., parsing >>> code to generate the config would seem to be more reliable, IMO. >>> However, you've dismissed that as unreasonable because the build >>> tool chain is unfamiliar with programming languages. In which case, >>> you'd need a custom tool to parse for each language. >> >> Yes, it would be user responsibility to ensure that the configs were >> correct for the code. Frankly, even if code scanners were to be >> written for every language and dialect they could not determine >> everything that a human knows about code limits so it's probably not >> possible to automate the specification. >> > > I generally, other than 32-bit, 16-bit, etc, don't know anything about > code limits. I let the code get the information from the compiler, if > I need to know. Do you seriously memorize all the output that Enquire.c > can produce? Do you do so for multiple platforms? Each C compiler can > a completely different set of values, even on the same machine. At > some point, you'll get all that info confused. > > https://homepages.cwi.nl/~steven/enquire.html Useful link! As for what you asked, I don't memorise limits, as such. But I do write C code which is portable. Basically, beyond a certain point the code doesn't care what the machine's word size is. For example, the code could require that words be at least 16 bits wide but beyond that not care how large they are. To me, that's one of the great things about HLL code: it can be used to generate code for various machines all from one source file. > >>>> I don't intend to emit a makefile. :-) >>>> >>>> The idea is that the build system would invoke compilers and other >>>> programs as needed. >>> >>> Why would I suspect that may be more complicated than emitting a >>> makefile? >> >> It probably would. But it might be easier in the long run to have a >> custom process. It's a critical-mass issue. There comes a point where >> the effort of working with existing tools becomes so great that it >> becomes better to make a new tool. >> > > Can I take it that you believe we've reached or exceeded the > critical-mass event as arbitrarily decided upon by you? ... If so, > what pushed you over the edge? It clearly wasn't any of Banksy's > irreverent artwork/graffiti. :-) > >>>> I was thinking more about cross compiling: one platform having >>>> compilers for different targets. >>> >>> Why? We've got cloud-computing. That doesn't mean every computer >>> in the cloud must be the same architecture. >>> >>> To answer my own "Why?", there are some situations where >>> cross-compiling might be preferred, e.g., producing code for an old >>> 8-bit. >> >> AISI compilers and assemblers are standard programs which read input >> and produce output. There's no a priori requirement for them to >> produce output for the type of machine they are running on. None at >> all. > >> A compiler which emits code for a 68040, for example, could run >> on a MIPS CPU or any other turing machine. > > True. But, this is usually because the compiler has been ported to > another architecture, e.g., the MIPS CPU etc, /after/ already being made > to work for the original host microprocessor and operating system, which > the compiler on a different platform is now cross-compiling for, e.g., > the 68040. > >> I don't understand the predominance of the idea that compilers must >> produce output for the machines they run on. > > I think you'd agree that the x86 has numerous processor modes: > RM16, VM16/E0/E1, PM16, PM32, CM16, CM32, PM64, Yes, and over the years the range has acquired numerous additional registers and instruction sets. > > and numerous operating systems: > MS-DOS, PC-DOS, IBM DOS, DR-DOS, IBM OS/2, Windows 3.1, Windows NT, > Windows 98, Windows SE, Windows ME, Windows Vista, Windows 7, Windows > 8, Windows 10, Linux and various Mac OSes. > > And, there are even more environments than that, as code could be > produced specifically for various DPMI hosts, VCPI hosts, EMS hosts, > XMS hosts, and DOS Extenders used with DOS. > > So, a native compiler must generate code for the specific processor > mode and the specific host operating system or environment. This must > be working /before/ producing a cross-compiler. I.e., you must produce > output for the machine the code runs on first, in order to make sure it > works, before transferring the tool chain to another architecture, in > order to cross-compile. > > Do you agree with that sequence of events? Yes and no. Yes, the compiler has to produce object code for the minimum CPU and instruction set. No, the compiler doesn't need to produce code for different environments; it can leave that to interfacing code and the linker. > >> That last link was very useful, thanks. By showing there are many >> build-automation systems it suggests that others have found that no >> one solution is the last word on the subject. And having looked at >> some of the more promising ones and seen that they each have their >> own faults, it's reassuring in two ways: first that solutions are not >> simple and second that it can be worth writing a custom one. >> > > Are you familiar with psychology? If not, look up confirmation bias. > It's a type of cognitive bias. There are 188 known cognitive biases. > These are types of defective decision-making or faulty logic built into > the human mind. Some are more serious than others. > > https://en.wikipedia.org/wiki/Confirmation_bias > > I.e., you could've just as easily come to the conclusion that the > existence of many build-automation systems suggests that the concept of > build-automation is not an effective solution in general. You also > could've concluded that since "each have their own faults," and that > since there are many systems, that there is no perfect solution to be > found. > > In other words, your conclusions seem to be arbitrary, i.e., you're > interested in this project, so you've characterized it in the best > possible light, while disregarding the possible negatives. What you are missing in that is the journey to get to this point. I've been bothered by make's limitations for YEARS, and looked for alternatives but none of them fix the things I believe to be wrong. So it is obviously sensible to consider alternatives. And as for your suggestion that no build-automation system is perfect, that's verging on the aphoristic. The make system is good. But it has its failings. Given that other people have come up with alternatives, how do you get to the point of saying that someone else considering an alternative is succumbing to confirmation bias? And aside from the work involved, what negatives of producing a new system do you think are being disregarded (your phrase)? > >>>> What CCC would do is >>>> >>>> 1. Look for a config file in sym which tells it what each of the >>>> source files in sym is capable of. >>> >>> If the extension specifies the compiler to run, wouldn't this >>> suffice much of the time? >> >> Not really. Let me give you an example. >> >> Say we have a C file which is to be compiled and it can become an >> object file for 16-bit or 32-bit x86. The compile command for 32-bit >> "$(target)" output might be something like >> >> cc -m32 -c $(src) -o $(target) >> >> By contrast, the 'recipe' for 16-bit output might be >> >> cc -c -m16 $(src) -o /dev/null >> cc -E -m16 --sysroot=/usr/lib/bcc $(src) \ >> | /usr/lib/bcc/unproto \ >> | /usr/lib/bcc/bcc-cc1 -0 \ >> | /usr/bin/as86 -u -w -0 -n $(src) -o $(target) >> > > If they're both for x86, I'd think they'd be far more similar than > that. I.e., I'd expect both similar to the first line. If > cross-compiling or building a standalone environment, I'd suspect > something more like the later. The first (for 32-bit) is a simple compile command. The second (for 16-bit) is in two parts. Part 1 runs a simple compiler first to generate error messages. I.e. it basically uses it as a lint program because it is more informative than the 16-bit compiler. Part 2 runs the cc preprocessor (because it can do more than the one which is supplied with the 16-bit compiler) and then pipes the result through relevant stages of the 16-bit compiler. > >> Basically, the command to be run would depend on the source file type >> /and/ the target file type. The full command including all options >> would depend on a lot more, but hopefully the above shows the idea. > > I would think that you could produce links or files with different > names, that are designed to execute the compiler in different ways. > E.g., > > (normal) > cc -m32 -c $(src) -o $(target) > > (cross) > cc-x -m32 -c $(src) -o $(target) > > Simply calling cc-x instead of cc, would do all the extra stuff. Of > course, this would depend on producing a script or batch file named > cc-x. You'd probably need something a like Linux shell, bash, on > targets which don't support it. Or, you could use a makefile with > make, ISTM. I have thought of something similar but in your view what would be the advantage of doing that rather than running commands directly? > >>>> 2. Iterate over the source files in sym. For each one: >>>> >>>> 2a. Work out all the different object files we can derive from >>>> it[*]. >>>> >>>> 2b. For each one, if it exists and is up to date then do nothing. >>>> >>>> 2c. For each which is missing or is not up to date ... build it. >>>> >>>> [*] Working out what object files we can derive from each source >>>> file is something I still have to come up with a mechanism for >>> >>> Do all these languages have the ability to have multi-line or block >>> comment sections? ... If so, you could place a specification >>> within a comment block near the start of the file. Then, you just >>> need some code to detect and extract the specification. This would >>> save you from needing to actually parse the code. >>> >>> Obviously, you probably want something unique to act as a flag or >>> magic value or sentinel to key off of to find the specification. >>> And, you may need to specify it is located within the first 100 or >>> so lines of the code, etc., e.g., for C, C++, NASM: >>> >>> /* */ >>> /*<James' build-tool specification start> */ >>> /* source C */ >>> /* build-target 32-bit */ >>> /* output COFF */ >>> /* </James' build-tool specification end> */ >>> /* */ >>> >>> // >>> //<James' build-tool specification start> >>> // source C++ >>> // build-target 64-bit >>> // output PE >>> //</James' build-tool specification end> >>> // >>> >>> ; >>> ;<James' build-tool specification start> >>> ; source NASM >>> ; build-target 16-bit >>> ; output DOS .EXE >>> ;</James' build-tool specification end> >>> ; >> >> For lots of reasons I am not sure why someone would do that. > > To avoid doing 2a: > >>>> 2a. Work out all the different object files we can derive from >>>> it[*]. > > The spec tells you "all the different object files we can derive from > it," upfront, or, it could, if you so wish. Wouldn't it be better to have a program work out the possible derivatives rather than having to specify them? You were arguing before for automation but now you seem to have switched to manual specification. > >> For >> example, if you had a folder with 20 files which all had the same >> specification why would you change each one? Wouldn't it be easier to >> just say that all files in that folder had a certain specification? >> > > If that's the case "that all files in that folder had a certain > specification," couldn't you assume that the first file has the correct > spec for the entire directory? If the first is deleted or renamed, > another file, with the same specification, would be first. Or, you > could just create a single file for the entire directory, which is > typically called a makefile or build script. Yes. Having a single config file for the entire directory is basically what I suggested earlier. The only difference is that I allowed for one config file to apply to subdirectories as well as its own directory. For security it would be a config file rather than a script or makefile. > >>> Why do they need to all be built at once? Can't you build one after >>> another? If so, then you can clean, set new target, build, save >>> output files, repeat. >> >> They don't, but building all at once could be the default. > > Without cloud computing or a compute farm of servers, I don't see how > that could be the case. Well, I guess they could compile on different > cores in parallel on the same machine, but that adds extra complexity as > the host OS must support it. What if someone is compiling on a > single-core machine or single-thread operating system? You simply can't > compile all at once by default. ... Sorry, I don't mean the builds being done in parallel. I just mean that they can all be done as a result of the running of one command. I.e. the command builds them all before it finishes. That could be in parallel or concurrently or one after another. > >> What I >> have in mind is to allow the set of targets to be restricted as >> needed. For example, if the build command is CCC, as before, then >> >> CCC folder >> >> would build all possible targets for all source files in that folder. > > Yup, that should be easy to do with the parallel processing available > with cloud computing, especially if all the original host architectures > are available to build with. I doubt they'd have something as old as a > PDP-7 in their farm, but they might have a Cray or two ... Of course, > you'd expect most of these farms to be x86 or ARM. I like the scale of your ideas ... but running on a single PC would do! > >> But >> >> CCC --cconv syscall --and --cpu arm folder >> >> would only build targets which were for Arm CPUs and used the syscall >> calling convention. (That's not a defined syntax, just a possible way >> of specifying the targets.) > > If you can compile one in the cloud, you can compile them all. (*) > > (*) I don't know if that's true, but it should be. There is no reason > it couldn't be. It only takes someone with the money and vision. > > > Rod Pemberton > -- James Harris
[toc] | [prev] | [next] | [standalone]
| From | Rod Pemberton <NoEmail@trraxvfeqa.prg> |
|---|---|
| Date | 2018-03-24 01:38 -0400 |
| Message-ID | <p94o5c$a88$1@gioia.aioe.org> |
| In reply to | #3936 |
On Wed, 21 Mar 2018 07:10:43 +0000 James Harris <james.harris.1@gmail.com> wrote: (snip) > Yes and no. ... > Yes, the compiler has to produce object code for the > minimum CPU and instruction set. Minimum? Who /wants/ to support RM16? ... > No, the compiler doesn't need to produce code for different > environments; it can leave that to interfacing code and the linker. ... So, one platform has sbrk() and another has mmap(). So, one platform has int 0x21, but another has syscall or sysenter. So, one platform has an OS call for argv, argc, but another must create their own. So, one platform has a POSIX compliant file I/O system, but another does not. I.e., I think issues like these, and others, would effectively require a software translation layer in between the host independent code your compiler is apparently producing, and the host dependent code the OS environment needs to execute the application. I believe this is needed in order to effect your belief that "the compiler doesn't need to produce code for different environments". E.g., for sbrk() vs. mmap(), you'd need a single function that would eventually map onto either sbrk() or mmap() depending on what the OS environment supports. Dealing with all of these issues (an more), will create a library of such interface functions, or a translation layer. > The make system is good. But it has its failings. Given that other > people have come up with alternatives, how do you get to the point of > saying that someone else considering an alternative is succumbing to > confirmation bias? Plenty have tried and failed, but one is attempting it yet again? (Yes, I'm guilty of that, if that's where you were headed.) My presumption is that if it is a serious enough problem and it is a problem that can be solved, then someone in academia, e.g, computer science professor, would've solved it by now, or maybe, a hacker would've stumbled across a workable solution already. Of course, it may be worthy to try an alternate solution. > And aside from the work involved, what negatives of producing a new > > system do you think are being disregarded (your phrase)? So, I'm not playing Devil's advocate now? I have no idea. I could assume there might be some incompatibilities between platforms that cause implementation problems, e.g., sequencing, or possibly, there might be difficulty in implementing a portable solution. This could be due to the commands needed or perhaps due to information needed from the compilers or assemblers. You could also have limitations or large differences where no easy cooperative solution works. Above, (snipped) the negatives were: a) "not an effective solution in general" b) "no perfect solution to be found" > >> Basically, the command to be run would depend on the source file > >> type /and/ the target file type. The full command including all > >> options would depend on a lot more, but hopefully the above shows > >> the idea. > > > > I would think that you could produce links or files with different > > names, that are designed to execute the compiler in different ways. > > E.g., > > > > (normal) > > cc -m32 -c $(src) -o $(target) > > > > (cross) > > cc-x -m32 -c $(src) -o $(target) > > > > Simply calling cc-x instead of cc, would do all the extra stuff. Of > > course, this would depend on producing a script or batch file named > > cc-x. You'd probably need something a like Linux shell, bash, on > > targets which don't support it. Or, you could use a makefile with > > make, ISTM. > > I have thought of something similar but in your view what would be > the advantage of doing that rather than running commands directly? If you meant typing commands in on the command line by "running commands directly," then you only have to type the shorter "cc-x ..." instead of the longer command, because the full commands are stored in a file or script. You also don't need to memorize the arguments or parameters either. If the config file or script or batch file is processed by a program, you can allow for all sorts of things to happen, e.g., input parameters, shifting of parameters, parsing/processing file names, directories, strings, do computations or accept user input, checks for files or directories or other file system operations, etc. > Wouldn't it be better to have a program work out the possible > derivatives rather than having to specify them? IMO, yes. > You were arguing before for automation but now you seem to have > switched to manual specification. Of course, but I thought you "rejected" the idea of parsing the code, or compiling a code snippet to determine this information. You wanted a specification of some sort, or seemed to. So, where do you put the specification? A separate file, which is extra work synchronizing, or embedded within the code? Comments are available, or should be, for every programming language, if you decide on embedding the specification within the code, instead of using separate control files or make files or scripts, etc. Arguing? Recommending. > Sorry, I don't mean the builds being done in parallel. I just mean > that they can all be done as a result of the running of one command. > I.e. the command builds them all before it finishes. That could be in > parallel or concurrently or one after another. So, forked/spawned builds (multi-process) at once for multiple platforms? Or, sequential, one platform after another? Rod Pemberton -- Facebook is dead. They banned Trump's campaign for a data breach, but looked the other way for Obama's campaign. So, why was it a breach of trust for Trump, Zuckerberg?
[toc] | [prev] | [next] | [standalone]
| From | James Harris <james.harris.1@gmail.com> |
|---|---|
| Date | 2018-03-24 16:10 +0000 |
| Message-ID | <p95taj$gam$1@dont-email.me> |
| In reply to | #3949 |
On 24/03/2018 05:38, Rod Pemberton wrote: > On Wed, 21 Mar 2018 07:10:43 +0000 > James Harris <james.harris.1@gmail.com> wrote: > > (snip) > >> Yes and no. > > ... > >> Yes, the compiler has to produce object code for the >> minimum CPU and instruction set. > > Minimum? Who /wants/ to support RM16? ... That's not what I mean. Say you want to run 32-bit x86 code. Your minimum CPU could be a 386. Alternatively, if you wanted to use YMM registers you would target a higher minimum CPU. Basically, whatever the target CPU is, the code will run on that CPU or higher. So any given object module will have been compiled for a certain minimum CPU. > >> No, the compiler doesn't need to produce code for different >> environments; it can leave that to interfacing code and the linker. > > ... > > So, one platform has sbrk() and another has mmap(). > > So, one platform has int 0x21, but another has syscall or sysenter. > > So, one platform has an OS call for argv, argc, but another must create > their own. > > So, one platform has a POSIX compliant file I/O system, but another does > not. > > > I.e., I think issues like these, and others, would effectively require > a software translation layer in between the host independent code > your compiler is apparently producing, and the host dependent code the > OS environment needs to execute the application. Exactly. I'd rather only link to the correct library code at load time but that's largely another topic and could not be done in all cases. For this thread, I was asking primarily about how to manage the process of building source code to object code, though there would be other applications. > I believe this is > needed in order to effect your belief that "the compiler doesn't need to > produce code for different environments". E.g., for sbrk() vs. > mmap(), you'd need a single function that would eventually map onto > either sbrk() or mmap() depending on what the OS environment supports. > Dealing with all of these issues (an more), will create a library of > such interface functions, or a translation layer. Yes, all true. > >> The make system is good. But it has its failings. Given that other >> people have come up with alternatives, how do you get to the point of >> saying that someone else considering an alternative is succumbing to >> confirmation bias? > > Plenty have tried and failed, but one is attempting it yet again? Not quite. Different people have different goals or different requirements. So it's only natural that there are different programs. ... >> Wouldn't it be better to have a program work out the possible >> derivatives rather than having to specify them? > > IMO, yes. > >> You were arguing before for automation but now you seem to have >> switched to manual specification. > > Of course, but I thought you "rejected" the idea of parsing the code, or > compiling a code snippet to determine this information. You wanted a > specification of some sort, or seemed to. So, where do you put the > specification? A separate file, which is extra work synchronizing, or > embedded within the code? Comments are available, or should be, for > every programming language, if you decide on embedding the > specification within the code, instead of using separate control files > or make files or scripts, etc. I found I would need to split the config into two parts or phases: specification and then consolidation. The first part would indicate attributes of individual source files. The second would use those attributes to decide what to do. To illustrate, consider these source files harness.nasm module.c The first will only work in x86-32. Let's assume that the second will compile for any target which has words of 32 bits or wider and let's say we want to compile it for certain x86, Mips and Arm targets. The 'specification' part would say "module.c needs at least 32-bit words". And the consolidation part would have to say things such as the following (simplified) where "..." represents the commands needed. * To build x86-32 from .nasm ... * To build x86-32 from .c ... * To build Mips-32 from .c ... * To build Arm-32 from .c ... * To build Arm-64 from .c ... There's a mixture of build targets in there just to make the point. In reality there could be quite a few more targets. Each would use three things to decide what commands to run. 1. the attributes identified by the specification 2. the type of the source and 3. the type of the target. In other words, the configurations will need to be written in two parts which are stored in different places. One part would be included with the source code and it would specify the attributes of the source files. The other part would be under the control of the user who was building the object files. On Unix this latter config could be in ~/ or /etc/ or both. Whether you consider that automated or manual, perhaps it at least shows a bit more clearly what I have in mind. > > Arguing? Recommending. > >> Sorry, I don't mean the builds being done in parallel. I just mean >> that they can all be done as a result of the running of one command. >> I.e. the command builds them all before it finishes. That could be in >> parallel or concurrently or one after another. > > So, forked/spawned builds (multi-process) at once for multiple > platforms? Or, sequential, one platform after another? Either. -- James Harris
[toc] | [prev] | [next] | [standalone]
| From | Rod Pemberton <NoEmail@trraxvfeqa.prg> |
|---|---|
| Date | 2018-03-24 20:05 -0400 |
| Message-ID | <p96p17$1hq9$3@gioia.aioe.org> |
| In reply to | #3956 |
On Sat, 24 Mar 2018 16:10:55 +0000 James Harris <james.harris.1@gmail.com> wrote: > On 24/03/2018 05:38, Rod Pemberton wrote: > I found I would need to split the config into two parts or phases: > specification and then consolidation. The first part would indicate > attributes of individual source files. The second would use those > attributes to decide what to do. > > To illustrate, consider these source files > > harness.nasm > module.c > > The first will only work in x86-32. Let's assume that the second will > compile for any target which has words of 32 bits or wider and let's > say we want to compile it for certain x86, Mips and Arm targets. > > The 'specification' part would say "module.c needs at least 32-bit > words". > > And the consolidation part would have to say things such as the > following (simplified) where "..." represents the commands needed. > > * To build x86-32 from .nasm ... > * To build x86-32 from .c ... > * To build Mips-32 from .c ... > * To build Arm-32 from .c ... > * To build Arm-64 from .c ... > > There's a mixture of build targets in there just to make the point. > In reality there could be quite a few more targets. Each would use > three things to decide what commands to run. My initial thought upon reading this was that you're combining a Make program's Makefile, i.e., 'specification part', with a generic compiler front end which is where the build-target is normally specified, but with control of the generic compiler front-end and the specified build-target moved out into the 'consolidation part', instead of using command-line parameters. Rod Pemberton -- Facebook is dead. They banned Trump's campaign for a data breach, but looked the other way for Obama's campaign. So, why was it a breach of trust, Zuckerberg?
[toc] | [prev] | [next] | [standalone]
| From | James Harris <james.harris.1@gmail.com> |
|---|---|
| Date | 2018-03-25 16:55 +0100 |
| Message-ID | <p98gqc$e8g$1@dont-email.me> |
| In reply to | #3958 |
On 25/03/2018 00:05, Rod Pemberton wrote:
> On Sat, 24 Mar 2018 16:10:55 +0000
> James Harris <james.harris.1@gmail.com> wrote:
>
>> On 24/03/2018 05:38, Rod Pemberton wrote:
>
>> I found I would need to split the config into two parts or phases:
>> specification and then consolidation. The first part would indicate
>> attributes of individual source files. The second would use those
>> attributes to decide what to do.
>>
>> To illustrate, consider these source files
>>
>> harness.nasm
>> module.c
>>
>> The first will only work in x86-32. Let's assume that the second will
>> compile for any target which has words of 32 bits or wider and let's
>> say we want to compile it for certain x86, Mips and Arm targets.
>>
>> The 'specification' part would say "module.c needs at least 32-bit
>> words".
>>
>> And the consolidation part would have to say things such as the
>> following (simplified) where "..." represents the commands needed.
>>
>> * To build x86-32 from .nasm ...
>> * To build x86-32 from .c ...
>> * To build Mips-32 from .c ...
>> * To build Arm-32 from .c ...
>> * To build Arm-64 from .c ...
>>
>> There's a mixture of build targets in there just to make the point.
>> In reality there could be quite a few more targets. Each would use
>> three things to decide what commands to run.
>
> My initial thought upon reading this was that you're combining a Make
> program's Makefile, i.e., 'specification part', with a generic compiler
> front end which is where the build-target is normally specified, but
> with control of the generic compiler front-end and the specified
> build-target moved out into the 'consolidation part', instead of
> using command-line parameters.
Sorry, it is a bit cryptic. I don't know if you saw my reply yesterday
to Andy but I put in a better example. It is basically as follows.
Say we have these files of source code.
x16/boot.nasm
x32/boot.nasm
x64/boot.nasm
body.c
SPECIFICATION PART
The config file that describes the code (call it Pbuild.cfg which would
be in the source tree) would say things like
x16/* bits=16 cpu=x86
x32/* bits=32 cpu=x86
x64/* bits=64 cpu=x86
That says that files in x16/ are for x86-16, and so on. "bits" and "cpu"
would be the relevant 'attributes' of the source files. For example, the
specification part tells the build system that
x64/boot.nasm
is for cpu=x86, bits=64.
Having no attributes for body.c would mean that it is portable, i.e. it
is not restricted to a certain CPU or word size or in any other way. In
practice, it might be better described as
*.c bits=16..
meaning that matching .c files are for targets which are 16-bit and larger.
Basically, each source file would be given attributes describing its
limitations.
CONSOLIDATION PART
This is the bit which would be more like a makefile. It would say how to
carry out each compile. The file name on Unix might be
~/.pbuild.cfg
In other words, it would be in the home directory of the person running
the builds. An alternative would be to have a system-wide configuration
file.
/etc/pbuild.cfg
Wherever it is stored its contents would indicate things like
to build 16-bit x86 code from .nasm sources
nasm -fas86 ...
to build 32-bit x86 code from .nasm sources
nasm -felf32 ...
to build 64-but x86 code from .nasm sources
nasm -felf64 ...
And for C files
to build 16-bit x86 code from .c sources
bcc ...
to build 32-bit x86 code from .c sources
cc -m32 ...
to build 64-but x86 code from .c sources
cc -m64 ...
where ... shows where other parameters would go.
The idea is that all such object files would be built or rebuilt
automatically, using the info in the aforementioned 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 currently see this working. Does it all make a bit more
sense now?
--
James Harris
[toc] | [prev] | [next] | [standalone]
| From | "Pascal J. Bourguignon" <pjb@informatimago.com> |
|---|---|
| Date | 2018-03-14 13:39 +0100 |
| Message-ID | <m2tvtirfui.fsf@despina.home> |
| In reply to | #3851 |
James Harris <james.harris.1@gmail.com> writes: > Irrespective of whether the build is being done under Unix or Windows > or whatever OS, what's a good way to specify the include folders > (e.g. on Unix those folder names which have to appear after -I on the > compiler command line) so that its easy enough even in a big project > to generate the necessary compile commands? So you know about the -I argument. Now to answer you question, you have to know what build system you are using. This is doable easily enough in makefiles. In more sophisticated cases, I would advise to use scons. -- __Pascal J. Bourguignon http://www.informatimago.com
[toc] | [prev] | [standalone]
Page 6 of 6 — ← Prev page 1 2 3 4 5 [6]
Back to top | Article view | comp.lang.misc
csiph-web