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

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

Universal Build System for C

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

Contents

  Universal Build System for C Thiago Adams <thiago.adams@gmail.com> - 2021-10-04 05:33 -0700
    Re: Universal Build System for C Branimir Maksimovic <branimir.maksimovic@icloud.com> - 2021-10-04 15:54 +0000
    Re: Universal Build System for C fir <profesor.fir@gmail.com> - 2021-10-04 09:26 -0700
      Re: Universal Build System for C fir <profesor.fir@gmail.com> - 2021-10-04 09:47 -0700
        Re: Universal Build System for C fir <profesor.fir@gmail.com> - 2021-10-04 10:13 -0700
          Re: Universal Build System for C fir <profesor.fir@gmail.com> - 2021-10-05 04:12 -0700
    Re: Universal Build System for C Guillaume <message@bottle.org> - 2021-10-04 19:49 +0200
      Re: Universal Build System for C Thiago Adams <thiago.adams@gmail.com> - 2021-10-04 11:00 -0700
    Re: Universal Build System for C Bart <bc@freeuk.com> - 2021-10-06 20:37 +0100
      Re: Universal Build System for C Thiago Adams <thiago.adams@gmail.com> - 2021-10-07 06:18 -0700
        Re: Universal Build System for C Thiago Adams <thiago.adams@gmail.com> - 2021-10-07 06:25 -0700
          Re: Universal Build System for C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-07 07:41 -0700
            Re: Universal Build System for C Thiago Adams <thiago.adams@gmail.com> - 2021-10-08 14:05 -0700
              Re: Universal Build System for C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-08 14:22 -0700
                Re: Universal Build System for C Thiago Adams <thiago.adams@gmail.com> - 2021-10-08 14:44 -0700
                  Re: Universal Build System for C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-10-08 23:25 +0100
                    Re: Universal Build System for C Thiago Adams <thiago.adams@gmail.com> - 2021-10-08 15:37 -0700
                Re: Universal Build System for C Bart <bc@freeuk.com> - 2021-10-08 22:51 +0100
                  Re: Universal Build System for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2021-10-09 01:39 -0700
                    Re: Universal Build System for C Bart <bc@freeuk.com> - 2021-10-09 11:00 +0100
                Re: Universal Build System for C scott@slp53.sl.home (Scott Lurndal) - 2021-10-10 18:09 +0000
                  8-bit ASCII (was Re: Universal Build System for C) scott@slp53.sl.home (Scott Lurndal) - 2021-10-10 20:55 +0000
              Re: Universal Build System for C Bart <bc@freeuk.com> - 2021-10-08 23:05 +0100
                Re: Universal Build System for C Thiago Adams <thiago.adams@gmail.com> - 2021-10-08 15:30 -0700
                  Re: Universal Build System for C Thiago Adams <thiago.adams@gmail.com> - 2021-10-08 18:12 -0700
                    Re: Universal Build System for C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-08 20:51 -0700
                      Re: Universal Build System for C David Brown <david.brown@hesbynett.no> - 2021-10-09 12:54 +0200
                        Re: Universal Build System for C Thiago Adams <thiago.adams@gmail.com> - 2021-10-09 06:30 -0700
                          Re: Universal Build System for C David Brown <david.brown@hesbynett.no> - 2021-10-09 17:29 +0200
              Re: Universal Build System for C Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2021-10-08 23:39 +0000
                Re: Universal Build System for C Thiago Adams <thiago.adams@gmail.com> - 2021-10-08 17:50 -0700
    Re: Universal Build System for C Thiago Adams <thiago.adams@gmail.com> - 2021-11-22 04:26 -0800
      Re: Universal Build System for C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-11-22 20:39 +0000
        Re: Universal Build System for C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-11-22 13:18 -0800
          Re: Universal Build System for C Bart <bc@freeuk.com> - 2021-11-22 21:49 +0000
            Re: Universal Build System for C scott@slp53.sl.home (Scott Lurndal) - 2021-11-23 14:45 +0000
              Re: Universal Build System for C Bart <bc@freeuk.com> - 2021-11-23 16:03 +0000
                Re: Universal Build System for C Thiago Adams <thiago.adams@gmail.com> - 2022-04-18 14:39 -0700
                  Re: Universal Build System for C Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2022-04-18 22:17 +0000
                  Re: Universal Build System for C Thiago Adams <thiago.adams@gmail.com> - 2022-04-18 16:07 -0700
          Re: Universal Build System for C scott@slp53.sl.home (Scott Lurndal) - 2021-11-23 14:44 +0000
        Re: Universal Build System for C Thiago Adams <thiago.adams@gmail.com> - 2021-11-22 16:19 -0800
          Re: Universal Build System for C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2021-11-23 01:00 +0000

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

#163068

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>Thiago Adams <thiago.adams@gmail.com> writes:
>> On Thursday, October 7, 2021 at 11:41:30 AM UTC-3, Keith Thompson wrote:

>>
>> I found this "Here is the code in C which will delete the executable after execution."
>> https://unix.stackexchange.com/questions/280067/have-rm-not-report-when-a-file-is-missing
>
>Deleting the executable after running it once is certainly valid, but
>not something you'd usually want to do.

This paradigm was quite common in the early days of computing;
compile and go where the data deck immediately followed the program
deck (particularly on systems without disk or with small disk(s)).

The HP-3000 supported compile and go (from cards or from the interactive
command interpreter) using 'PASS' files.   The logical name $OLDPASS
referred to an unnamed input temporary file and $NEWPASS to an unamed output temporary
file - the compiler would write to $NEWPASS, the segmenter (linker) would read from
$OLDPASS and write to $NEWPASS and $NEWPASS would be executed.

The paradigm fit educational computer science programs quite well in the
days before disk storage became routinely affordable.

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

#163069 — 8-bit ASCII (was Re: Universal Build System for C)

scott@slp53.sl.home (Scott Lurndal) writes:
>Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>Thiago Adams <thiago.adams@gmail.com> writes:
>>> On Thursday, October 7, 2021 at 11:41:30 AM UTC-3, Keith Thompson wrote:
>
>>>
>>> I found this "Here is the code in C which will delete the executable after execution."
>>> https://unix.stackexchange.com/questions/280067/have-rm-not-report-when-a-file-is-missing
>>
>>Deleting the executable after running it once is certainly valid, but
>>not something you'd usually want to do.
>
>This paradigm was quite common in the early days of computing;
>compile and go where the data deck immediately followed the program
>deck (particularly on systems without disk or with small disk(s)).
>
>The HP-3000 supported compile and go (from cards or from the interactive
>command interpreter) using 'PASS' files.   The logical name $OLDPASS
>referred to an unnamed input temporary file and $NEWPASS to an unamed output temporary
>file - the compiler would write to $NEWPASS, the segmenter (linker) would read from
>$OLDPASS and write to $NEWPASS and $NEWPASS would be executed.
>
>The paradigm fit educational computer science programs quite well in the
>days before disk storage became routinely affordable.

Following up on topic from a few months ago, relative to 8-bit ASCII
character evolution at ANSI, I found the spec I had referred to then:

ANSI X3.41-1974 (AKA FIPS-35)
American National Standard code extension techniques for use with the 7-bit coded character
set of american national standard code for information interchange.

https://nvlpubs.nist.gov/nistpubs/Legacy/FIPS/fipspub35.pdf

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

#163053

On 08/10/2021 22:05, Thiago Adams wrote:
> On Thursday, October 7, 2021 at 11:41:30 AM UTC-3, Keith Thompson wrote:
>> Thiago Adams <thiago...@gmail.com> writes:
>>> On Thursday, October 7, 2021 at 10:18:13 AM UTC-3, Thiago Adams wrote:
>>>> On Wednesday, October 6, 2021 at 4:38:07 PM UTC-3, Bart wrote:
>>>>> On 04/10/2021 13:33, Thiago Adams wrote:
>>>>>>
>>>>>> In 2020 we had a topic here talking about build systems.
>>>>>> https://groups.google.com/g/comp.lang.c/c/pkn6Iw3V0pc/m/0Cn_oqi5BgAJ
>>>>>>
>>>>>> Let's say I want to publish a lib/executable with source.
>>>>>>
>>>>>> This are the instructions:
>>>>>>
>>>>>> For windows:
>>>>>>
>>>>>> Open VC++ command prompt and type.
>>>>>>
>>>>>> cl build.c & build
>>>>> This is even neater than I thought it would be.
>>>>>
>>>>> However, shouldn't & be &&? (&& won't run build if the compile fails; &
>>>>> might still do so.)
>>>> && is much better thanks!
>>>> and && works in Linux and Windows in the same way.
>>>
>>> We can also delete the build executable at the end like this
>>>
>>> WINDOWS:
>>> cl build.c && build.exe || del build.exe
>>>
>>> LINUX
>>> gcc build.c -o build && ./build || rm build
>> Normally if the compilation fails the executable won't be created. If
>> you're concerned about a pre-existing executable, you can remove it
>> before compiling. (And consider the behavior of the del or rm command
>> if it's asked to delete a file that doesn't exist.)
>>
> 
> We can use:
> 
> WINDOWS
> cl build.c && build & del /q  build.exe
> 
> LINUX
> gcc  build.c -o build && ./build ; rm -f build
> 
> In this case, at end the build, the executable is always deleted
> if present and no error printed.

If you put too much on one line, it will starts to be more of a script. 
You examples also repeat 'build' 3-4 times which is a bad sign.

However you don't need to provide such a script yourself. Any programmer 
will know how to create their own scripts if they want, if they know 
that the build process is:

    Compile build.c to an executable using their compiler of choice
    Run that executable
    Optionally delete the build program if they want

Your example command lines also assume a certain compiler, but I got the 
impression that build.c would pick up the compiler used, and use the 
same one for the application.

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

#163055

On Friday, October 8, 2021 at 7:06:04 PM UTC-3, Bart wrote:
> On 08/10/2021 22:05, Thiago Adams wrote: 
> > On Thursday, October 7, 2021 at 11:41:30 AM UTC-3, Keith Thompson wrote: 
> >> Thiago Adams <thiago...@gmail.com> writes: 
> >>> On Thursday, October 7, 2021 at 10:18:13 AM UTC-3, Thiago Adams wrote: 
> >>>> On Wednesday, October 6, 2021 at 4:38:07 PM UTC-3, Bart wrote: 
> >>>>> On 04/10/2021 13:33, Thiago Adams wrote: 
> >>>>>> 
> >>>>>> In 2020 we had a topic here talking about build systems. 
> >>>>>> https://groups.google.com/g/comp.lang.c/c/pkn6Iw3V0pc/m/0Cn_oqi5BgAJ 
> >>>>>> 
> >>>>>> Let's say I want to publish a lib/executable with source. 
> >>>>>> 
> >>>>>> This are the instructions: 
> >>>>>> 
> >>>>>> For windows: 
> >>>>>> 
> >>>>>> Open VC++ command prompt and type. 
> >>>>>> 
> >>>>>> cl build.c & build 
> >>>>> This is even neater than I thought it would be. 
> >>>>> 
> >>>>> However, shouldn't & be &&? (&& won't run build if the compile fails; & 
> >>>>> might still do so.) 
> >>>> && is much better thanks! 
> >>>> and && works in Linux and Windows in the same way. 
> >>> 
> >>> We can also delete the build executable at the end like this 
> >>> 
> >>> WINDOWS: 
> >>> cl build.c && build.exe || del build.exe 
> >>> 
> >>> LINUX 
> >>> gcc build.c -o build && ./build || rm build 
> >> Normally if the compilation fails the executable won't be created. If 
> >> you're concerned about a pre-existing executable, you can remove it 
> >> before compiling. (And consider the behavior of the del or rm command 
> >> if it's asked to delete a file that doesn't exist.) 
> >> 
> > 
> > We can use: 
> > 
> > WINDOWS 
> > cl build.c && build & del /q build.exe 
> > 
> > LINUX 
> > gcc build.c -o build && ./build ; rm -f build 
> > 
> > In this case, at end the build, the executable is always deleted 
> > if present and no error printed.
> If you put too much on one line, it will starts to be more of a script. 
> You examples also repeat 'build' 3-4 times which is a bad sign. 
Yes.
 
> However you don't need to provide such a script yourself. Any programmer 
> will know how to create their own scripts if they want, if they know 
> that the build process is: 
Sure.
  
> Compile build.c to an executable using their compiler of choice 
> Run that executable 
> Optionally delete the build program if they want 
> 
> Your example command lines also assume a certain compiler, but I got the 
> impression that build.c would pick up the compiler used, and use the 
> same one for the application.

I already had a situation where the compiler that creates the build is not
the same of the target.  I have a build that uses emscripten  to generate
javascript or wasm.

I put a define 
cl -DWEB build.c  && build
and hardcoded the emscripten  optons.
But I also had other problems that emscripten  needs environment variables ..etc..

In windows the compiler is defined my the VC command prompt. You select
the one you want.

For Linux it is using default but I guess it could auto select as well, or show
some options..

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

#163059

On Friday, October 8, 2021 at 7:30:24 PM UTC-3, Thiago Adams wrote:
...
> For Linux it is using default but I guess it could auto select as well, or show 
> some options..

This is what I found how to change default gcc (because build script has hardcoded gcc)

 "
1. Open the terminal window in LINUX and execute the command:
          $ which gcc
      This will provide the symbolic link (softlink) to the default version of GCC.
   2. Navigate to the directory which has this softlink.
      Change the softlink to point to the version of GCC that you want to use.
      For example, for a standard GCC version 4.7 installed (where the compiler command is put at /usr/bin/gcc-4.7),
      this can be done using the following command:
          $ sudo ln -f -s /usr/bin/gcc-4.7 gcc
"
from
https://www.mathworks.com/matlabcentral/answers/454659-how-can-i-change-my-current-gcc-g-version-to-a-supported-one


also added 
system(""gcc --version") inside the build script to know
what version is being used.

this is an extra step , however I guess all linux programmers 
must know about this.

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

#163060

Thiago Adams <thiago.adams@gmail.com> writes:
> On Friday, October 8, 2021 at 7:30:24 PM UTC-3, Thiago Adams wrote:
> ...
>> For Linux it is using default but I guess it could auto select as well, or show 
>> some options..
>
> This is what I found how to change default gcc (because build script has hardcoded gcc)
>
>  "
> 1. Open the terminal window in LINUX and execute the command:
>           $ which gcc
>       This will provide the symbolic link (softlink) to the default version of GCC.
>    2. Navigate to the directory which has this softlink.
>       Change the softlink to point to the version of GCC that you want to use.
>       For example, for a standard GCC version 4.7 installed (where the compiler command is put at /usr/bin/gcc-4.7),
>       this can be done using the following command:
>           $ sudo ln -f -s /usr/bin/gcc-4.7 gcc
> "
> from
> https://www.mathworks.com/matlabcentral/answers/454659-how-can-i-change-my-current-gcc-g-version-to-a-supported-one
>
>
> also added 
> system(""gcc --version") inside the build script to know
> what version is being used.
>
> this is an extra step , however I guess all linux programmers 
> must know about this.

That's bad advice.  Telling users to mess around with system-owned
directories like /usr/bin is dangerous.  I know Linux pretty well, and I
don't do that myself.

On my system, for example, /usr/bin/gcc is a symbolic link to "gcc-9",
which is provided by the "gcc-9" package.  That package provides 55
files; the compiler executable is just one of them.  If I manually
change just the /usr/bin/gcc symlink, I'm likely to leave my system in
an inconsistent state.

And g++ (the C++ compiler) is provided by another package "g++9", which
should normally be kept in synch with the gcc package.

On Ubuntu, the "update-alternatives" command can be used to safely
change the default version of a command.  Other systems are likely to
have something similar.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

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

#163065

On 09/10/2021 05:51, Keith Thompson wrote:
> Thiago Adams <thiago.adams@gmail.com> writes:
>> On Friday, October 8, 2021 at 7:30:24 PM UTC-3, Thiago Adams wrote:
>> ...
>>> For Linux it is using default but I guess it could auto select as well, or show 
>>> some options..
>>
>> This is what I found how to change default gcc (because build script has hardcoded gcc)
>>
>>  "
>> 1. Open the terminal window in LINUX and execute the command:
>>           $ which gcc
>>       This will provide the symbolic link (softlink) to the default version of GCC.
>>    2. Navigate to the directory which has this softlink.
>>       Change the softlink to point to the version of GCC that you want to use.
>>       For example, for a standard GCC version 4.7 installed (where the compiler command is put at /usr/bin/gcc-4.7),
>>       this can be done using the following command:
>>           $ sudo ln -f -s /usr/bin/gcc-4.7 gcc
>> "
>> from
>> https://www.mathworks.com/matlabcentral/answers/454659-how-can-i-change-my-current-gcc-g-version-to-a-supported-one
>>
>>
>> also added 
>> system(""gcc --version") inside the build script to know
>> what version is being used.
>>
>> this is an extra step , however I guess all linux programmers 
>> must know about this.
> 
> That's bad advice.  Telling users to mess around with system-owned
> directories like /usr/bin is dangerous.  I know Linux pretty well, and I
> don't do that myself.
> 
> On my system, for example, /usr/bin/gcc is a symbolic link to "gcc-9",
> which is provided by the "gcc-9" package.  That package provides 55
> files; the compiler executable is just one of them.  If I manually
> change just the /usr/bin/gcc symlink, I'm likely to leave my system in
> an inconsistent state.
> 
> And g++ (the C++ compiler) is provided by another package "g++9", which
> should normally be kept in synch with the gcc package.
> 
> On Ubuntu, the "update-alternatives" command can be used to safely
> change the default version of a command.  Other systems are likely to
> have something similar.
> 

Ubuntu gets that from Debian, and so the same method is usable for other
Debian-based distributions.

As a general point, if you want to be sure you are using gcc version 9,
I'd much rather write "gcc-9" than change the system default.  For my
embedded work, I have the exact compiler (indeed full toolchain,
including library and headers) specified in the project makefile.

You can also happily put symbolic links in ~/bin, or /usr/local/bin,
giving your own choice of names and linking to whatever versions of
programs you want.  That too is far better than messing with /usr/bin.

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

#163066

On Saturday, October 9, 2021 at 7:54:18 AM UTC-3, David Brown wrote:
> On 09/10/2021 05:51, Keith Thompson wrote: 
> > Thiago Adams <thiago...@gmail.com> writes: 
> >> On Friday, October 8, 2021 at 7:30:24 PM UTC-3, Thiago Adams wrote: 
> >> ... 
> >>> For Linux it is using default but I guess it could auto select as well, or show 
> >>> some options.. 
> >> 
> >> This is what I found how to change default gcc (because build script has hardcoded gcc) 
> >> 
> >> " 
> >> 1. Open the terminal window in LINUX and execute the command: 
> >> $ which gcc 
> >> This will provide the symbolic link (softlink) to the default version of GCC. 
> >> 2. Navigate to the directory which has this softlink. 
> >> Change the softlink to point to the version of GCC that you want to use. 
> >> For example, for a standard GCC version 4.7 installed (where the compiler command is put at /usr/bin/gcc-4.7), 
> >> this can be done using the following command: 
> >> $ sudo ln -f -s /usr/bin/gcc-4.7 gcc 
> >> " 
> >> from 
> >> https://www.mathworks.com/matlabcentral/answers/454659-how-can-i-change-my-current-gcc-g-version-to-a-supported-one 
> >> 
> >> 
> >> also added 
> >> system(""gcc --version") inside the build script to know 
> >> what version is being used. 
> >> 
> >> this is an extra step , however I guess all linux programmers 
> >> must know about this. 
> > 
> > That's bad advice. Telling users to mess around with system-owned 
> > directories like /usr/bin is dangerous. I know Linux pretty well, and I 
> > don't do that myself. 
> > 
> > On my system, for example, /usr/bin/gcc is a symbolic link to "gcc-9", 
> > which is provided by the "gcc-9" package. That package provides 55 
> > files; the compiler executable is just one of them. If I manually 
> > change just the /usr/bin/gcc symlink, I'm likely to leave my system in 
> > an inconsistent state. 
> > 
> > And g++ (the C++ compiler) is provided by another package "g++9", which 
> > should normally be kept in synch with the gcc package. 
> > 
> > On Ubuntu, the "update-alternatives" command can be used to safely 
> > change the default version of a command. Other systems are likely to 
> > have something similar. 
> >
> Ubuntu gets that from Debian, and so the same method is usable for other 
> Debian-based distributions. 
> 
> As a general point, if you want to be sure you are using gcc version 9, 
> I'd much rather write "gcc-9" than change the system default. For my 
> embedded work, I have the exact compiler (indeed full toolchain, 
> including library and headers) specified in the project makefile. 
> 
> You can also happily put symbolic links in ~/bin, or /usr/local/bin, 
> giving your own choice of names and linking to whatever versions of 
> programs you want. That too is far better than messing with /usr/bin.

If the name of gcc is fixed like gcc-10 gcc-11 etc..
I can create the following macro:

    #define STR(a) #a
    #define F(a)  STR(a)
    #define GCC  F(gcc-__GNUC__)

    GCC
  
  This macro expand to "gcc-11" "gcc-10" etc..

 Then
  gcc-11 build.c && ./build

would use gcc-11 to create the "build script" and the build script would
use "gcc-11" to compile the target.

It is very nice we can use the preprocessor. For instance
if the code does not support gcc < 7 I can show an error

#if __GNUC__ < 7
#error "this build requires gcc > 7"
#endif

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

#163067

On 09/10/2021 15:30, Thiago Adams wrote:
> On Saturday, October 9, 2021 at 7:54:18 AM UTC-3, David Brown wrote:
>> On 09/10/2021 05:51, Keith Thompson wrote: 
>>> Thiago Adams <thiago...@gmail.com> writes: 
>>>> On Friday, October 8, 2021 at 7:30:24 PM UTC-3, Thiago Adams wrote: 
>>>> ... 
>>>>> For Linux it is using default but I guess it could auto select as well, or show 
>>>>> some options.. 
>>>>
>>>> This is what I found how to change default gcc (because build script has hardcoded gcc) 
>>>>
>>>> " 
>>>> 1. Open the terminal window in LINUX and execute the command: 
>>>> $ which gcc 
>>>> This will provide the symbolic link (softlink) to the default version of GCC. 
>>>> 2. Navigate to the directory which has this softlink. 
>>>> Change the softlink to point to the version of GCC that you want to use. 
>>>> For example, for a standard GCC version 4.7 installed (where the compiler command is put at /usr/bin/gcc-4.7), 
>>>> this can be done using the following command: 
>>>> $ sudo ln -f -s /usr/bin/gcc-4.7 gcc 
>>>> " 
>>>> from 
>>>> https://www.mathworks.com/matlabcentral/answers/454659-how-can-i-change-my-current-gcc-g-version-to-a-supported-one 
>>>>
>>>>
>>>> also added 
>>>> system(""gcc --version") inside the build script to know 
>>>> what version is being used. 
>>>>
>>>> this is an extra step , however I guess all linux programmers 
>>>> must know about this. 
>>>
>>> That's bad advice. Telling users to mess around with system-owned 
>>> directories like /usr/bin is dangerous. I know Linux pretty well, and I 
>>> don't do that myself. 
>>>
>>> On my system, for example, /usr/bin/gcc is a symbolic link to "gcc-9", 
>>> which is provided by the "gcc-9" package. That package provides 55 
>>> files; the compiler executable is just one of them. If I manually 
>>> change just the /usr/bin/gcc symlink, I'm likely to leave my system in 
>>> an inconsistent state. 
>>>
>>> And g++ (the C++ compiler) is provided by another package "g++9", which 
>>> should normally be kept in synch with the gcc package. 
>>>
>>> On Ubuntu, the "update-alternatives" command can be used to safely 
>>> change the default version of a command. Other systems are likely to 
>>> have something similar. 
>>>
>> Ubuntu gets that from Debian, and so the same method is usable for other 
>> Debian-based distributions. 
>>
>> As a general point, if you want to be sure you are using gcc version 9, 
>> I'd much rather write "gcc-9" than change the system default. For my 
>> embedded work, I have the exact compiler (indeed full toolchain, 
>> including library and headers) specified in the project makefile. 
>>
>> You can also happily put symbolic links in ~/bin, or /usr/local/bin, 
>> giving your own choice of names and linking to whatever versions of 
>> programs you want. That too is far better than messing with /usr/bin.
> 
> If the name of gcc is fixed like gcc-10 gcc-11 etc..

This may vary by distribution or installation.  If the user puts there
own links in ~/bin, they can decide the names themselves.

> I can create the following macro:
> 
>     #define STR(a) #a
>     #define F(a)  STR(a)
>     #define GCC  F(gcc-__GNUC__)
> 
>     GCC
>   
>   This macro expand to "gcc-11" "gcc-10" etc..
> 
>  Then
>   gcc-11 build.c && ./build
> 
> would use gcc-11 to create the "build script" and the build script would
> use "gcc-11" to compile the target.
> 
> It is very nice we can use the preprocessor. For instance
> if the code does not support gcc < 7 I can show an error
> 
> #if __GNUC__ < 7
> #error "this build requires gcc > 7"
> #endif
> 

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

#163057

On Fri, 08 Oct 2021 14:05:17 -0700, Thiago Adams wrote:

> On Thursday, October 7, 2021 at 11:41:30 AM UTC-3, Keith Thompson wrote:
>> Thiago Adams <thiago...@gmail.com> writes:
>> > On Thursday, October 7, 2021 at 10:18:13 AM UTC-3, Thiago Adams
>> > wrote:
>> >> On Wednesday, October 6, 2021 at 4:38:07 PM UTC-3, Bart wrote:
>> >> > On 04/10/2021 13:33, Thiago Adams wrote:
>> >> > > 
>> >> > > In 2020 we had a topic here talking about build systems.
>> >> > > https://groups.google.com/g/comp.lang.c/c/pkn6Iw3V0pc/
m/0Cn_oqi5BgAJ
>> >> > > 
>> >> > > Let's say I want to publish a lib/executable with source.
>> >> > > 
>> >> > > This are the instructions:
>> >> > > 
>> >> > > For windows:
>> >> > > 
>> >> > > Open VC++ command prompt and type.
>> >> > > 
>> >> > > cl build.c & build
>> >> > This is even neater than I thought it would be.
>> >> > 
>> >> > However, shouldn't & be &&? (&& won't run build if the compile
>> >> > fails; &
>> >> > might still do so.)
>> >> && is much better thanks!
>> >> and && works in Linux and Windows in the same way.
>> > 
>> > We can also delete the build executable at the end like this
>> > 
>> > WINDOWS:
>> > cl build.c && build.exe || del build.exe
>> > 
>> > LINUX gcc build.c -o build && ./build || rm build
>> Normally if the compilation fails the executable won't be created. If
>> you're concerned about a pre-existing executable, you can remove it
>> before compiling. (And consider the behavior of the del or rm command
>> if it's asked to delete a file that doesn't exist.)
>> 
>> 
> We can use:
> 
> WINDOWS cl build.c && build & del /q  build.exe
> 
> LINUX gcc  build.c -o build && ./build ; rm -f build
> 
> In this case, at end the build, the executable is always deleted if
> present and no error printed.
> 
> temporary files like build.obj can be deleted inside build.exe.
> But it cannot delete itself at the end. Right?

I'm amused that you think that the /only/ platforms that a "Universal
Build System for C" must support are Microsoft Windows, and Linux.

To paraphrase Hamlet, "There are more platforms in current use and
planning, Thiago, then are dreamt of in your philosophy."

And, FWIW, many of those /other/ platforms (that this "Universal
Build System" neglects or ignores) would not permit a "build system"
that arbitrarily, and without audit, deletes files and programs.


[snip]
-- 
Lew Pitcher
"In Skills, We Trust"

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

#163058

On Friday, October 8, 2021 at 8:39:14 PM UTC-3, Lew Pitcher wrote:
> On Fri, 08 Oct 2021 14:05:17 -0700, Thiago Adams wrote: 
> 
> > On Thursday, October 7, 2021 at 11:41:30 AM UTC-3, Keith Thompson wrote: 
> >> Thiago Adams <thiago...@gmail.com> writes: 
> >> > On Thursday, October 7, 2021 at 10:18:13 AM UTC-3, Thiago Adams 
> >> > wrote: 
> >> >> On Wednesday, October 6, 2021 at 4:38:07 PM UTC-3, Bart wrote: 
> >> >> > On 04/10/2021 13:33, Thiago Adams wrote: 
> >> >> > > 
> >> >> > > In 2020 we had a topic here talking about build systems. 
> >> >> > > https://groups.google.com/g/comp.lang.c/c/pkn6Iw3V0pc/ 
> m/0Cn_oqi5BgAJ 
> >> >> > > 
> >> >> > > Let's say I want to publish a lib/executable with source. 
> >> >> > > 
> >> >> > > This are the instructions: 
> >> >> > > 
> >> >> > > For windows: 
> >> >> > > 
> >> >> > > Open VC++ command prompt and type. 
> >> >> > > 
> >> >> > > cl build.c & build 
> >> >> > This is even neater than I thought it would be. 
> >> >> > 
> >> >> > However, shouldn't & be &&? (&& won't run build if the compile 
> >> >> > fails; & 
> >> >> > might still do so.) 
> >> >> && is much better thanks! 
> >> >> and && works in Linux and Windows in the same way. 
> >> > 
> >> > We can also delete the build executable at the end like this 
> >> > 
> >> > WINDOWS: 
> >> > cl build.c && build.exe || del build.exe 
> >> > 
> >> > LINUX gcc build.c -o build && ./build || rm build 
> >> Normally if the compilation fails the executable won't be created. If 
> >> you're concerned about a pre-existing executable, you can remove it 
> >> before compiling. (And consider the behavior of the del or rm command 
> >> if it's asked to delete a file that doesn't exist.) 
> >> 
> >> 
> > We can use: 
> > 
> > WINDOWS cl build.c && build & del /q build.exe 
> > 
> > LINUX gcc build.c -o build && ./build ; rm -f build 
> > 
> > In this case, at end the build, the executable is always deleted if 
> > present and no error printed. 
> > 
> > temporary files like build.obj can be deleted inside build.exe. 
> > But it cannot delete itself at the end. Right?
> I'm amused that you think that the /only/ platforms that a "Universal 
> Build System for C" must support are Microsoft Windows, and Linux. 

I gave a basic sample. The idea is more universal than
the sample itself.
 
"#else
#error Unknown Platform/Compiler
#endif
"
when you have this error you can add another platform compiler.

Basically the requirements are:

-  C compiler (the platform already have)
-  Standard function system from  <stdlib.h>.

(Of course we can build for Arduino, but the compiler is
not inside it)

> To paraphrase Hamlet, "There are more platforms in current use and 
> planning, Thiago, then are dreamt of in your philosophy." 
> 
> And, FWIW, many of those /other/ platforms (that this "Universal 
> Build System" neglects or ignores) would not permit a "build system" 
> that arbitrarily, and without audit, deletes files and programs. 

This is optional.

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

#163569

On Monday, October 4, 2021 at 9:34:03 AM UTC-3, Thiago Adams wrote:

[...]
"
  if (system("cl " 
       SOURCE_FILES   
       " -o output_file.exe") != 0) 
 {
    exit(1); 
  }
"


I little update:
When I wrote the script using "system"  I didn't know that system on linux 
does not return the exit code of the application it executes.
So instead of system I am using a "cmd" function that is:

//ON WINDOWS
int cmd(const char* command) {
    return system(command);
}

//ON LINUX
#include <sys/wait.h>
int cmd(const char* command) {
    int test_result = system(command);
    int stat = 0;
    wait(&stat);
    if (WIFEXITED(stat)) {
        test_result = WEXITSTATUS(stat);
    }
    else if (WIFSIGNALED(stat)) {
        test_result = WTERMSIG(stat);
    }
    return test_result;
}

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

#163571

Thiago Adams <thiago.adams@gmail.com> writes:

> On Monday, October 4, 2021 at 9:34:03 AM UTC-3, Thiago Adams wrote:
>
> [...]
> "
>   if (system("cl " 
>        SOURCE_FILES   
>        " -o output_file.exe") != 0) 
>  {
>     exit(1); 
>   }
> "
>
>
> I little update:
> When I wrote the script using "system"  I didn't know that system on linux 
> does not return the exit code of the application it executes.

This is not really a C question.  What system will report is very much
determined by the implementation.

If all goes well (there is a non-null argument and a shell that can be
executed) then it returns the exit status of the shell.  That's the exit
status of the last comment the shell ran.

Why is this not good enough?

> So instead of system I am using a "cmd" function that is:
>
> //ON WINDOWS
> int cmd(const char* command) {
>     return system(command);
> }

I would be surprised if Windows implementations of system did not have
the some very similar issues.  Surely system can fail for all sorts of
reasons.

> //ON LINUX
> #include <sys/wait.h>
> int cmd(const char* command) {
>     int test_result = system(command);
>     int stat = 0;
>     wait(&stat);
>     if (WIFEXITED(stat)) {
>         test_result = WEXITSTATUS(stat);
>     }
>     else if (WIFSIGNALED(stat)) {
>         test_result = WTERMSIG(stat);
>     }
>     return test_result;
> }

I don't know what you are trying to do here, but this looks wrong.  The
code in 'system' should have already "waited" for it's child pid, so
that wait should fail.  You don't look at the return value so you can't
tell that it fails.

I think you should consider posting in comp.unix.programmer if you want
to unravel all the details of what system might return.

-- 
Ben.

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

#163574

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Thiago Adams <thiago.adams@gmail.com> writes:
>
>> On Monday, October 4, 2021 at 9:34:03 AM UTC-3, Thiago Adams wrote:
>>
>> [...]
>> "
>>   if (system("cl " 
>>        SOURCE_FILES   
>>        " -o output_file.exe") != 0) 
>>  {
>>     exit(1); 
>>   }
>> "
>>
>>
>> I little update:
>> When I wrote the script using "system"  I didn't know that system on linux 
>> does not return the exit code of the application it executes.
>
> This is not really a C question.  What system will report is very much
> determined by the implementation.
>
> If all goes well (there is a non-null argument and a shell that can be
> executed) then it returns the exit status of the shell.  That's the exit
> status of the last comment the shell ran.
>
> Why is this not good enough?

On POSIX systems, system() returns an int value from which the shell's
exit status can be extracted.  For example, /bin/false does the
equivalent of exit(1), but system("/bin/false") will (very probably)
return 256, not 1.

[...]

> I think you should consider posting in comp.unix.programmer if you want
> to unravel all the details of what system might return.

Agreed.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips
void Void(void) { Void(); } /* The recursive call of the void */

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

#163576

On 22/11/2021 21:18, Keith Thompson wrote:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> Thiago Adams <thiago.adams@gmail.com> writes:
>>
>>> On Monday, October 4, 2021 at 9:34:03 AM UTC-3, Thiago Adams wrote:
>>>
>>> [...]
>>> "
>>>    if (system("cl "
>>>         SOURCE_FILES
>>>         " -o output_file.exe") != 0)
>>>   {
>>>      exit(1);
>>>    }
>>> "
>>>
>>>
>>> I little update:
>>> When I wrote the script using "system"  I didn't know that system on linux
>>> does not return the exit code of the application it executes.
>>
>> This is not really a C question.  What system will report is very much
>> determined by the implementation.
>>
>> If all goes well (there is a non-null argument and a shell that can be
>> executed) then it returns the exit status of the shell.  That's the exit
>> status of the last comment the shell ran.
>>
>> Why is this not good enough?
> 
> On POSIX systems, system() returns an int value from which the shell's
> exit status can be extracted.  For example, /bin/false does the
> equivalent of exit(1), but system("/bin/false") will (very probably)
> return 256, not 1.

My tests show that system() on Linux returns the last byte of the return 
code, left shifted by 8 bits.

So a program returning 0x12345678 will yield 0x7800 when run from 
system(). Maybe a simpler wrapper function for the OP then.

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

#163595

Bart <bc@freeuk.com> writes:
>On 22/11/2021 21:18, Keith Thompson wrote:
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>> Thiago Adams <thiago.adams@gmail.com> writes:
>>>
>>>> On Monday, October 4, 2021 at 9:34:03 AM UTC-3, Thiago Adams wrote:
>>>>
>>>> [...]
>>>> "
>>>>    if (system("cl "
>>>>         SOURCE_FILES
>>>>         " -o output_file.exe") != 0)
>>>>   {
>>>>      exit(1);
>>>>    }
>>>> "
>>>>
>>>>
>>>> I little update:
>>>> When I wrote the script using "system"  I didn't know that system on linux
>>>> does not return the exit code of the application it executes.
>>>
>>> This is not really a C question.  What system will report is very much
>>> determined by the implementation.
>>>
>>> If all goes well (there is a non-null argument and a shell that can be
>>> executed) then it returns the exit status of the shell.  That's the exit
>>> status of the last comment the shell ran.
>>>
>>> Why is this not good enough?
>> 
>> On POSIX systems, system() returns an int value from which the shell's
>> exit status can be extracted.  For example, /bin/false does the
>> equivalent of exit(1), but system("/bin/false") will (very probably)
>> return 256, not 1.
>
>My tests show that system() on Linux returns the last byte of the return 
>code, left shifted by 8 bits.

$ man 3 system

Will describe the exact format of the return value and document
the macros used to extract the exit status.

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

#163599

On 23/11/2021 14:45, Scott Lurndal wrote:
> Bart <bc@freeuk.com> writes:
>> On 22/11/2021 21:18, Keith Thompson wrote:
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>> Thiago Adams <thiago.adams@gmail.com> writes:
>>>>
>>>>> On Monday, October 4, 2021 at 9:34:03 AM UTC-3, Thiago Adams wrote:
>>>>>
>>>>> [...]
>>>>> "
>>>>>     if (system("cl "
>>>>>          SOURCE_FILES
>>>>>          " -o output_file.exe") != 0)
>>>>>    {
>>>>>       exit(1);
>>>>>     }
>>>>> "
>>>>>
>>>>>
>>>>> I little update:
>>>>> When I wrote the script using "system"  I didn't know that system on linux
>>>>> does not return the exit code of the application it executes.
>>>>
>>>> This is not really a C question.  What system will report is very much
>>>> determined by the implementation.
>>>>
>>>> If all goes well (there is a non-null argument and a shell that can be
>>>> executed) then it returns the exit status of the shell.  That's the exit
>>>> status of the last comment the shell ran.
>>>>
>>>> Why is this not good enough?
>>>
>>> On POSIX systems, system() returns an int value from which the shell's
>>> exit status can be extracted.  For example, /bin/false does the
>>> equivalent of exit(1), but system("/bin/false") will (very probably)
>>> return 256, not 1.
>>
>> My tests show that system() on Linux returns the last byte of the return
>> code, left shifted by 8 bits.
> 
> $ man 3 system
> 
> Will describe the exact format of the return value and document
> the macros used to extract the exit status.
> 

I'd looked at this:

https://man7.org/linux/man-pages/man3/system.3.html

(first google hit for 'man system'), and couldn't make head or tail of 
the return value.

If now further look at the waitpid(2) link, it's just a rabbit hole that 
makes even less sense.

Doing my brief experiment was much more productive.

(In any case, I'd be using system() from a number of languages not just 
C, where C macros are not meaningful.)

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

#165732

On Tuesday, November 23, 2021 at 1:03:54 PM UTC-3, Bart wrote:
> On 23/11/2021 14:45, Scott Lurndal wrote: 
> > Bart <b...@freeuk.com> writes: 
> >> On 22/11/2021 21:18, Keith Thompson wrote: 
> >>> Ben Bacarisse <ben.u...@bsb.me.uk> writes: 
> >>>> Thiago Adams <thiago...@gmail.com> writes: 
> >>>> 
> >>>>> On Monday, October 4, 2021 at 9:34:03 AM UTC-3, Thiago Adams wrote: 
> >>>>> 
> >>>>> [...] 
> >>>>> " 
> >>>>> if (system("cl " 
> >>>>> SOURCE_FILES 
> >>>>> " -o output_file.exe") != 0) 
> >>>>> { 
> >>>>> exit(1); 
> >>>>> } 
> >>>>> " 
> >>>>> 
> >>>>> 
> >>>>> I little update: 
> >>>>> When I wrote the script using "system" I didn't know that system on linux 
> >>>>> does not return the exit code of the application it executes. 
> >>>> 
> >>>> This is not really a C question. What system will report is very much 
> >>>> determined by the implementation. 
> >>>> 
> >>>> If all goes well (there is a non-null argument and a shell that can be 
> >>>> executed) then it returns the exit status of the shell. That's the exit 
> >>>> status of the last comment the shell ran. 
> >>>> 
> >>>> Why is this not good enough? 
> >>> 
> >>> On POSIX systems, system() returns an int value from which the shell's 
> >>> exit status can be extracted. For example, /bin/false does the 
> >>> equivalent of exit(1), but system("/bin/false") will (very probably) 
> >>> return 256, not 1. 
> >> 
> >> My tests show that system() on Linux returns the last byte of the return 
> >> code, left shifted by 8 bits. 
> > 
> > $ man 3 system 
> > 
> > Will describe the exact format of the return value and document 
> > the macros used to extract the exit status. 
> >
> I'd looked at this: 
> 
> https://man7.org/linux/man-pages/man3/system.3.html 
> 
> (first google hit for 'man system'), and couldn't make head or tail of 
> the return value. 
> 
> If now further look at the waitpid(2) link, it's just a rabbit hole that 
> makes even less sense. 
> 
> Doing my brief experiment was much more productive. 
> 
> (In any case, I'd be using system() from a number of languages not just 
> C, where C macros are not meaningful.)

Update: "Packages" (experimental idea)

Let's say we want to use some lib3. (lib is a collection of source files in a folder)
This library depends on lib2 that depends on lib1.

I want to include lib3 in my project and lib1 is already used.

What I want to show is that using preprocessor and the ideas already presented 
here in the past we can "merge" the source files required by each lib.

Basically:

Each library has a "package.h" that includes other "package.h" required 
and also includes its own source files.

For instance: (lib3/package.h)

#ifndef LIB3_INCLUDED
#define LIB3_INCLUDED
#include "../Lib1/package.h"
#include "../Lib2/package.h"
" lib2/lib3.c "
#endif

We could have similar file for Lib2 including lib1

Then to compile the files required I just include the packages and the 
correct source files will be included just once.

    if (system("gcc"
#include "lib3/package.h"
        " main.c "
         " -o out) != 0)
  {
    exit(1);
  }

In case I already have lib1 included

    if (system("gcc"
#include "lib1/package.h"
#include "lib3/package.h"
        " main.c "
         " -o out) != 0)
  {
    exit(1);
  }

no problem.
Removing lib3 does not remove lib1.

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

#165733

On Mon, 18 Apr 2022 14:39:28 -0700, Thiago Adams wrote:
[snip]
> Update: "Packages" (experimental idea)
> 
> Let's say we want to use some lib3. (lib is a collection of source files in a folder)
> This library depends on lib2 that depends on lib1.
> 
> I want to include lib3 in my project and lib1 is already used.
> 
> What I want to show is that using preprocessor and the ideas already presented 
> here in the past we can "merge" the source files required by each lib.
> 
> Basically:
> 
> Each library has a "package.h" that includes other "package.h" required 
> and also includes its own source files.
[snip]


  .-'---`-.
,'          `.
|             \
|              \
\           _  \
,\  _    ,'-,/-)\
( * \ \,' ,' ,'-)
 `._,)     -',-')
   \/         ''/
    )        / /
   /       ,'-'

-- 
Lew Pitcher
"In Skills, We Trust"

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

#165735

On Monday, April 18, 2022 at 6:39:35 PM UTC-3, Thiago Adams wrote:
> On Tuesday, November 23, 2021 at 1:03:54 PM UTC-3, Bart wrote: 
> > On 23/11/2021 14:45, Scott Lurndal wrote: 
> > > Bart <b...@freeuk.com> writes: 
> > >> On 22/11/2021 21:18, Keith Thompson wrote: 
> > >>> Ben Bacarisse <ben.u...@bsb.me.uk> writes: 
> > >>>> Thiago Adams <thiago...@gmail.com> writes: 
> > >>>> 
> > >>>>> On Monday, October 4, 2021 at 9:34:03 AM UTC-3, Thiago Adams wrote: 
> > >>>>> 
> > >>>>> [...] 
> > >>>>> " 
> > >>>>> if (system("cl " 
> > >>>>> SOURCE_FILES 
> > >>>>> " -o output_file.exe") != 0) 
> > >>>>> { 
> > >>>>> exit(1); 
> > >>>>> } 
> > >>>>> " 
> > >>>>> 
> > >>>>> 
> > >>>>> I little update: 
> > >>>>> When I wrote the script using "system" I didn't know that system on linux 
> > >>>>> does not return the exit code of the application it executes. 
> > >>>> 
> > >>>> This is not really a C question. What system will report is very much 
> > >>>> determined by the implementation. 
> > >>>> 
> > >>>> If all goes well (there is a non-null argument and a shell that can be 
> > >>>> executed) then it returns the exit status of the shell. That's the exit 
> > >>>> status of the last comment the shell ran. 
> > >>>> 
> > >>>> Why is this not good enough? 
> > >>> 
> > >>> On POSIX systems, system() returns an int value from which the shell's 
> > >>> exit status can be extracted. For example, /bin/false does the 
> > >>> equivalent of exit(1), but system("/bin/false") will (very probably) 
> > >>> return 256, not 1. 
> > >> 
> > >> My tests show that system() on Linux returns the last byte of the return 
> > >> code, left shifted by 8 bits. 
> > > 
> > > $ man 3 system 
> > > 
> > > Will describe the exact format of the return value and document 
> > > the macros used to extract the exit status. 
> > > 
> > I'd looked at this: 
> > 
> > https://man7.org/linux/man-pages/man3/system.3.html 
> > 
> > (first google hit for 'man system'), and couldn't make head or tail of 
> > the return value. 
> > 
> > If now further look at the waitpid(2) link, it's just a rabbit hole that 
> > makes even less sense. 
> > 
> > Doing my brief experiment was much more productive. 
> > 
> > (In any case, I'd be using system() from a number of languages not just 
> > C, where C macros are not meaningful.)
> Update: "Packages" (experimental idea) 
> 
> Let's say we want to use some lib3. (lib is a collection of source files in a folder) 
> This library depends on lib2 that depends on lib1. 
> 
> I want to include lib3 in my project and lib1 is already used. 
> 
> What I want to show is that using preprocessor and the ideas already presented 
> here in the past we can "merge" the source files required by each lib. 
> 
> Basically: 
> 
> Each library has a "package.h" that includes other "package.h" required 
> and also includes its own source files. 
> 
> For instance: (lib3/package.h) 
> 
> #ifndef LIB3_INCLUDED 
> #define LIB3_INCLUDED 
> #include "../Lib1/package.h" 
> #include "../Lib2/package.h" 
> " lib2/lib3.c " 
> #endif 
> 
> We could have similar file for Lib2 including lib1 
> 
> Then to compile the files required I just include the packages and the 
> correct source files will be included just once. 
> 
> if (system("gcc" 
> #include "lib3/package.h" 
> " main.c " 
> " -o out) != 0) 
> { 
> exit(1); 
> } 
> 
> In case I already have lib1 included 
> 
> if (system("gcc" 
> #include "lib1/package.h" 
> #include "lib3/package.h" 
> " main.c " 
> " -o out) != 0) 
> { 
> exit(1); 
> } 
> 
> no problem. 
> Removing lib3 does not remove lib1.

Just to add a little more context.. One alternative solution used today is 
amalgamated files. Like sqlite amalgamated version.

The problem with amalgamated files is that if you want to
create a lib that depends on sqlite and  you want your lib
to be amalgamated as well you cannot merge both. 

A second lib from another programmer could do the same 
creating linking problems because the sqlite was added twice
with external linkage.

Another solution is to think that each lib has just one source file.
But having just one source file can be hard to maintaining during the
development of your lib/program.

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

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

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

csiph-web