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

#162977 — Universal Build System for C

In 2020 we had a topic here talking about build systems.
https://groups.google.com/g/comp.lang.c/c/pkn6Iw3V0pc/m/0Cn_oqi5BgAJ

The idea of having a standard way to generate the executable/lib 
was in my mind since the previous topics like the one we talked about
"#pragma source" being a way to find source code needed for compilation
in a standard way.

My idea was split the problem in two

1) Generate code from source (something standard in all compilers, descriptive)
2) Everything else (script to sign code, publish, generate installer etc)
some imperative script language.

At some point Bart said:

"Since this is for C, why not use C itself for the 'script' language? At
least it will be portable to the same targets as the program that is
being built. And since a C compiler is already needed, it won't
introduce another dependency."

This was a great advice! 
Bart also posted a sample 
(https://groups.google.com/g/comp.lang.c/c/pkn6Iw3V0pc/m/6k501ZBzBwAJ)
where he created a build for lua concatenating strings and options and 
them calling the compiler using system.

I have been using a "build script in C" for some months now I am really
happy with it! 

The main idea still the same but I am not using dynamic string concatenation
and I auto detect the compiler/platform when I use the same compiler that 
generates the build script and target. 
This is very handy! I don't need/want anymore any "standard way to compile" 
or any universal script. I am pretty happy with the way we can do this today.

This is the basic build script 

#define SOURCE_FILES " file1.c " \
                     " file2.c "

int main()
{

#if defined(_WIN32) && defined(_MSC_VER) && !defined(__clang__)

#define VC_DEBUG_OPTIONS   " /Od /MDd /RTC1 "
#define VC_RELEASE_OPTIONS " /GL /Gy /O2 /MD  "
#define VC_COMMON_OPTIONS  " /permissive- /GS /Zc:preprocessor- /std:c17  /W4 /Zc:wchar_t /Zi /Gm- /sdl /Zc:inline /fp:precise /errorReport:prompt  /WX /Zc:forScope /Gd /Oy- /FC /EHsc /nologo /diagnostics:column "

    /*
    * cl build.c & build
    */
  
    if (system("cl "
           SOURCE_FILES
           VC_RELEASE_OPTIONS
           " -D_CRT_SECURE_NO_WARNINGS "
           " -o output_file.exe") != 0) exit(1);

#elif defined(_WIN32) && defined(__clang__)
    
    /*
    * clang build.c -o build.exe & build
    */

    system("clang  "
           SOURCE_FILES
           " -D_CRT_SECURE_NO_WARNINGS "
           " -std=c17 "
           " -D_MT "
           " -Xlinker /NODEFAULTLIB "
           " -lucrt.lib -lvcruntime.lib -lmsvcrt.lib "
           " -lKernel32.lib -lUser32.lib -lAdvapi32.lib"
           " -luuid.lib -lWs2_32.lib -lRpcrt4.lib -lBcrypt.lib "
           " -o output_file.exe");

#elif defined(__linux__) && defined(__clang__)
    
    /*
    *  clang  build.c -o build ; ./build
    */
    system("clang  "
           SOURCE_FILES
           " -D_CRT_SECURE_NO_WARNINGS "
           " -std=c17 "
           " -Wall "
           " -o output_file");

#elif defined(__linux__) && defined(__GNUC__)
    
    /*
    *  gcc  build.c -o build ; ./build
    */
    system("gcc  -Wall"
           SOURCE_FILES
           " -DNDEBUG"
           " -o output_file");

#else 
 #error Unknown Platform/Compiler
#endif

}


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

or (if you want clang)

clang build.c -o build.exe & build 


for linux:

gcc  build.c -o build ; ./build

or

clang  build.c -o build ; ./build

- Nothing extra to install 
- Multiplatform
- We can debug or create complex logic using C
- etc..


I am still using normal VC++ build during the development
but I am using this script to create the final executable
to create/rum unit tests etc..

I recommend this approach.

[toc] | [next] | [standalone]

#162981

On 2021-10-04, Thiago Adams <thiago.adams@gmail.com> 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
>
> The idea of having a standard way to generate the executable/lib 
> was in my mind since the previous topics like the one we talked about
> "#pragma source" being a way to find source code needed for compilation
> in a standard way.
>
> I recommend this approach.
Thanks, I'll try.>


-- 

7-77-777
Evil Sinner!
to weak you should be meek, and you should brainfuck stronger
https://github.com/rofl0r/chaos-pp

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

#162983

poniedziałek, 4 października 2021 o 14:34:03 UTC+2 Thiago Adams napisał(a):
> In 2020 we had a topic here talking about build systems. 
> https://groups.google.com/g/comp.lang.c/c/pkn6Iw3V0pc/m/0Cn_oqi5BgAJ 
> 
> The idea of having a standard way to generate the executable/lib 
> was in my mind since the previous topics like the one we talked about 
> "#pragma source" being a way to find source code needed for compilation 
> in a standard way. 
> 
many make build systems and many, i guess, would like to see them universal 

c is language that dont support itself a clean building and it is another flaw of this great language.. i think if i could gather myself to say few words on this..

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

#162984

poniedziałek, 4 października 2021 o 18:26:29 UTC+2 fir napisał(a):
> poniedziałek, 4 października 2021 o 14:34:03 UTC+2 Thiago Adams napisał(a): 
> > In 2020 we had a topic here talking about build systems. 
> > https://groups.google.com/g/comp.lang.c/c/pkn6Iw3V0pc/m/0Cn_oqi5BgAJ 
> > 
> > The idea of having a standard way to generate the executable/lib 
> > was in my mind since the previous topics like the one we talked about 
> > "#pragma source" being a way to find source code needed for compilation 
> > in a standard way. 
> >
> many make build systems and many, i guess, would like to see them universal 
> 
> c is language that dont support itself a clean building and it is another flaw of this great language.. i think if i could gather myself to say few words on this..

may say soem in short

c has a flaw which is it dont support the way of expresing of cohesion of its code pieces which can be used to build monolitic outcome piece... i mean there is a need to express this cohesion on source pieces and another express the cohesion to non source pieces which may  be redistrubuables or expected to be present 

i think best way (at least in some way) would be to add it on source level amking no another kind of blot is to be needed..i think this should work like that that if you press enter on code pieces its gets compiled and if you press somethink like alt+enter there is a check of integrity - if all dependant pieces are present (yawn)

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

#162985

poniedziałek, 4 października 2021 o 18:47:45 UTC+2 fir napisał(a):
> poniedziałek, 4 października 2021 o 18:26:29 UTC+2 fir napisał(a): 
> > poniedziałek, 4 października 2021 o 14:34:03 UTC+2 Thiago Adams napisał(a): 
> > > In 2020 we had a topic here talking about build systems. 
> > > https://groups.google.com/g/comp.lang.c/c/pkn6Iw3V0pc/m/0Cn_oqi5BgAJ 
> > > 
> > > The idea of having a standard way to generate the executable/lib 
> > > was in my mind since the previous topics like the one we talked about 
> > > "#pragma source" being a way to find source code needed for compilation 
> > > in a standard way. 
> > > 
> > many make build systems and many, i guess, would like to see them universal 
> > 
> > c is language that dont support itself a clean building and it is another flaw of this great language.. i think if i could gather myself to say few words on this..
> may say soem in short 
> 
> c has a flaw which is it dont support the way of expresing of cohesion of its code pieces which can be used to build monolitic outcome piece... i mean there is a need to express this cohesion on source pieces and another express the cohesion to non source pieces which may be redistrubuables or expected to be present 
> 
> i think best way (at least in some way) would be to add it on source level amking no another kind of blot is to be needed..i think this should work like that that if you press enter on code pieces its gets compiled and if you press somethink like alt+enter there is a check of integrity - if all dependant pieces are present (yawn)

im not quite sure but possibly one keyword or one pragma is needed, there is just need to put expected/needed pieces in that keyword or pragma and that is all

main.c:

uses add.c, kernel.dll, some.bmp

int main()
{
  //...........
}

not to say that it looks good but and should be like that, more as illustration how to include  this cohesion data - and probably that is all needed as build system ...im not 100 % sure though

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

#163004

poniedziałek, 4 października 2021 o 19:13:44 UTC+2 fir napisał(a):
> poniedziałek, 4 października 2021 o 18:47:45 UTC+2 fir napisał(a):
> > poniedziałek, 4 października 2021 o 18:26:29 UTC+2 fir napisał(a): 
> > > poniedziałek, 4 października 2021 o 14:34:03 UTC+2 Thiago Adams napisał(a): 
> > > > In 2020 we had a topic here talking about build systems. 
> > > > https://groups.google.com/g/comp.lang.c/c/pkn6Iw3V0pc/m/0Cn_oqi5BgAJ 
> > > > 
> > > > The idea of having a standard way to generate the executable/lib 
> > > > was in my mind since the previous topics like the one we talked about 
> > > > "#pragma source" being a way to find source code needed for compilation 
> > > > in a standard way. 
> > > > 
> > > many make build systems and many, i guess, would like to see them universal 
> > > 
> > > c is language that dont support itself a clean building and it is another flaw of this great language.. i think if i could gather myself to say few words on this.. 
> > may say soem in short 
> > 
> > c has a flaw which is it dont support the way of expresing of cohesion of its code pieces which can be used to build monolitic outcome piece... i mean there is a need to express this cohesion on source pieces and another express the cohesion to non source pieces which may be redistrubuables or expected to be present 
> > 
> > i think best way (at least in some way) would be to add it on source level amking no another kind of blot is to be needed..i think this should work like that that if you press enter on code pieces its gets compiled and if you press somethink like alt+enter there is a check of integrity - if all dependant pieces are present (yawn)
> im not quite sure but possibly one keyword or one pragma is needed, there is just need to put expected/needed pieces in that keyword or pragma and that is all 
> 
> main.c: 
> 
> uses add.c, kernel.dll, some.bmp 
> 
> int main() 
> { 
> //........... 
> } 
> 
> not to say that it looks good but and should be like that, more as illustration how to include this cohesion data - and probably that is all needed as build system ...im not 100 % sure though

some could say i could change the word uses on attach etc but the problem is it probably looks to much 'modern' and the stylistical form of old c is kinda broken

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

#162987

Le 04/10/2021 à 14:33, Thiago Adams a écrit :
> 
> In 2020 we had a topic here talking about build systems.
> https://groups.google.com/g/comp.lang.c/c/pkn6Iw3V0pc/m/0Cn_oqi5BgAJ
> 
> The idea of having a standard way to generate the executable/lib
> was in my mind since the previous topics like the one we talked about
> "#pragma source" being a way to find source code needed for compilation
> in a standard way.

There are more build tools these days that you can think of.
Why yet another one?

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

#162988

On Monday, October 4, 2021 at 2:49:25 PM UTC-3, Guillaume wrote:
> Le 04/10/2021 à 14:33, Thiago Adams a écrit : 
> > 
> > In 2020 we had a topic here talking about build systems. 
> > https://groups.google.com/g/comp.lang.c/c/pkn6Iw3V0pc/m/0Cn_oqi5BgAJ 
> > 
> > The idea of having a standard way to generate the executable/lib 
> > was in my mind since the previous topics like the one we talked about 
> > "#pragma source" being a way to find source code needed for compilation 
> > in a standard way.
> There are more build tools these days that you can think of. 
> Why yet another one?

- Zero dependencies
- Zero learning curve (if you use command line compiler)
- Can debug
- Powerful
- Has preprocessor included (you can pass flags in your build)
- Can detects platform and compiler automatically (including compiler version and flags)
- Multiplatform
- Well established platform
- Simple instructions to build
- ...

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

#163031

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

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

#163041

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.

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

#163042

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

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

#163043

Thiago Adams <thiago.adams@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.)

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

#163049

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

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

#163050

Thiago Adams <thiago.adams@gmail.com> writes:
> 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 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.

If you use a Makefile rather than a hypothetical "universal build
system", typing "make clean" will delete any files that can be
regenerated, and "make build" will recreate the file "build" only if it
doesn't exist or has been invalidated (for example if "build.c" has been
modified more recently than "build").  (Determining what depends on what
can be tricky.)

A universal build system should at least provide most of the
functionality provided by existing ones.  If it can only build from
scratch, it's less useful.

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

#163051

On Friday, October 8, 2021 at 6:23:05 PM UTC-3, Keith Thompson wrote:
> Thiago Adams <thiago...@gmail.com> writes: 
> > 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 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. 
> 
> If you use a Makefile rather than a hypothetical "universal build 
> system", typing "make clean" will delete any files that can be 
> regenerated, and "make build" will recreate the file "build" only if it 
> doesn't exist or has been invalidated (for example if "build.c" has been 
> modified more recently than "build"). (Determining what depends on what 
> can be tricky.) 
> 
> A universal build system should at least provide most of the 
> functionality provided by existing ones. If it can only build from 
> scratch, it's less useful.


Something I may have a complete wrong view is that I am not
debugging at Linux. I don't know how others do this process?
IDE? I may try visual studio code in the future for this.

I can say how I do on Windows...I still use VC++ project/solution files 
and building inside Visual Studio because this is the way I press F5 and 
debug all the time. (This is not full build like run unit test all the time)

To create a multiplatform build script, to check all compilers
clang gcc cl this build.c is very handy and working very well with
no dependencies.


-----------

This code can be used to self delete file on linux and windows.
(linux remove works)

#ifdef _WIN32
int get_self_path(char* buffer, int maxsize)
{
    DWORD r = GetModuleFileNameA(NULL, buffer, maxsize);
    return r;
}
#else
int get_self_path(char* buffer, int maxsize)
{
    memset(buffer, 0, maxsize); // readlink does not null terminate!
    return readlink("/proc/self/exe", buffer, maxsize);    
}
#endif

int main()
{
    char szModuleName[200];
    get_self_path(szModuleName, sizeof szModuleName);

#ifdef _WIN32    
    char szCmd[2 * MAX_PATH];
    STARTUPINFO si = { 0 };
    PROCESS_INFORMATION pi = { 0 };
    StringCbPrintfA(szCmd, 2 * MAX_PATH, "cmd.exe /C timeout /t 3 && del /f /q \"%s\"", szModuleName);
    CreateProcessA(NULL, szCmd, NULL, NULL, FALSE, CREATE_NO_WINDOW, NULL, NULL, &si, &pi);
    CloseHandle(pi.hThread);
    CloseHandle(pi.hProcess);
#else
    remove(szModuleName);
#endif
}

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

#163054

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

> This code can be used to self delete file on linux and windows.
> (linux remove works)

Does remove (a standard C function) not work in this situation on
Windows?

> #ifdef _WIN32
> int get_self_path(char* buffer, int maxsize)
> {
>     DWORD r = GetModuleFileNameA(NULL, buffer, maxsize);

According to online sources, GetModuleFileNameA does not always null
terminate the string on some versions of Windows.  Maybe you know you
are not running this code on old versions.

You don't check (in either version) for the result being too long for
the buffer.  This is a serious concern, since you go right ahead and
delete the resulting named file, even if it is not the one you should be
deleting!

>     return r;
> }
> #else
> int get_self_path(char* buffer, int maxsize)
> {
>     memset(buffer, 0, maxsize); // readlink does not null terminate!

There is no need to zero the buffer.  readlink returns the number of
characters written so you can use that to know where to write a null.
And if you pass maxsize and the return is maxsize you know that there
was not enough room in the buffer for the path name to be written.

>     return readlink("/proc/self/exe", buffer, maxsize);    
> }
> #endif
>
> int main()
> {
>     char szModuleName[200];
>     get_self_path(szModuleName, sizeof szModuleName);
>
> #ifdef _WIN32    
>     char szCmd[2 * MAX_PATH];
>     STARTUPINFO si = { 0 };
>     PROCESS_INFORMATION pi = { 0 };
>     StringCbPrintfA(szCmd, 2 * MAX_PATH, "cmd.exe /C timeout /t 3 && del /f /q \"%s\"", szModuleName);

For this purpose, I don't see a problem, but just in case someone
decides to copy this code for other uses, I'll point out how dangerous
it is to run commands on string that might not be properly quoted.  And,
anyway, it's an excuse to post my favourite XKCD strip:

https://xkcd.com/327/

>     CreateProcessA(NULL, szCmd, NULL, NULL, FALSE, CREATE_NO_WINDOW, NULL, NULL, &si, &pi);
>     CloseHandle(pi.hThread);
>     CloseHandle(pi.hProcess);

That's a lot of work, so I presume just calling remove does not work.

> #else
>     remove(szModuleName);
> #endif
> }
>

-- 
Ben.

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

#163056

On Friday, October 8, 2021 at 7:25:49 PM UTC-3, Ben Bacarisse wrote:
> Thiago Adams <thiago...@gmail.com> writes: 
> 
> > This code can be used to self delete file on linux and windows. 
> > (linux remove works)
> Does remove (a standard C function) not work in this situation on 
> Windows?

It works in linux and windows it gives access error.

> > #ifdef _WIN32 
> > int get_self_path(char* buffer, int maxsize) 
> > { 
> > DWORD r = GetModuleFileNameA(NULL, buffer, maxsize);
> According to online sources, GetModuleFileNameA does not always null 
> terminate the string on some versions of Windows. Maybe you know you 
> are not running this code on old versions. 
> 
> You don't check (in either version) for the result being too long for 
> the buffer. This is a serious concern, since you go right ahead and 
> delete the resulting named file, even if it is not the one you should be 
> deleting!
> > return r; 
> > } 
> > #else 
> > int get_self_path(char* buffer, int maxsize) 
> > { 
> > memset(buffer, 0, maxsize); // readlink does not null terminate!
> There is no need to zero the buffer. readlink returns the number of 
> characters written so you can use that to know where to write a null. 
> And if you pass maxsize and the return is maxsize you know that there 
> was not enough room in the buffer for the path name to be written.
> > return readlink("/proc/self/exe", buffer, maxsize); 
> > } 
> > #endif 
> > 
> > int main() 
> > { 
> > char szModuleName[200]; 
> > get_self_path(szModuleName, sizeof szModuleName); 
> > 
> > #ifdef _WIN32 
> > char szCmd[2 * MAX_PATH]; 
> > STARTUPINFO si = { 0 }; 
> > PROCESS_INFORMATION pi = { 0 }; 
> > StringCbPrintfA(szCmd, 2 * MAX_PATH, "cmd.exe /C timeout /t 3 && del /f /q \"%s\"", szModuleName);
> For this purpose, I don't see a problem, but just in case someone 
> decides to copy this code for other uses, I'll point out how dangerous 
> it is to run commands on string that might not be properly quoted. And, 
> anyway, it's an excuse to post my favourite XKCD strip: 
> 
> https://xkcd.com/327/
> > CreateProcessA(NULL, szCmd, NULL, NULL, FALSE, CREATE_NO_WINDOW, NULL, NULL, &si, &pi); 
> > CloseHandle(pi.hThread); 
> > CloseHandle(pi.hProcess);
> That's a lot of work, so I presume just calling remove does not work. 


Thanks for the tips..
This auto clean is not so important for the build script, as Bart also 
have pointed out. 
But I will use this technique to create the "uninstall.exe"  that is also created by
the "build.c script".

I wish something like "update" that:

- download installer.exe from web (maybe a http client that downloads from github)
- run installer.exe
- installer runs previous uninstall.exe (if exist)
- previous uninstall.exe deletes the correct version and then itself 
  (useful in case not called by update)
- installer copies files to destination
- done!

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

#163052

On 08/10/2021 22:22, Keith Thompson wrote:
> Thiago Adams <thiago.adams@gmail.com> writes:

>> temporary files like build.obj can be deleted inside
>> build.exe.
>> But it cannot delete itself at the end. Right?
>>
>> 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.
> 
> If you use a Makefile rather than a hypothetical "universal build
> system", typing "make clean" will delete any files that can be
> regenerated, and "make build" will recreate the file "build" only if it
> doesn't exist or has been invalidated (for example if "build.c" has been
> modified more recently than "build").  (Determining what depends on what
> can be tricky.)
> 
> A universal build system should at least provide most of the
> functionality provided by existing ones.  If it can only build from
> scratch, it's less useful.
> 

It depends on what its for. It you're developing an application then you 
will need to build it 100 times a day or more. You might the ability to 
do incremental compilation.

But for a one-off build of some downloaded project, it will have to 
compile everything from scratch anyway. Then it can be done much more 
simply.

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

#163061

On Friday, 8 October 2021 at 22:52:21 UTC+1, Bart wrote:
> 
> It depends on what its for. It you're developing an application then you 
> will need to build it 100 times a day or more. You might the ability to 
> do incremental compilation. 
> 
> But for a one-off build of some downloaded project, it will have to 
> compile everything from scratch anyway. Then it can be done much more 
> simply.
>
We  do an "integration build" whenever a unit of work is finished (we use JIRA
and gitflow, a task is entered as a JIRA, a task branch is started, then it is merged
into the develop branch when it is completed). Merging into the develop branch
automatically triggers a complete re-build from scratch for all platforms.

This caught a problem yesterday. I had entered some data as long string literals.
The compiler I was using accepted the strings. But one of the Windows compilers
rejected them as too long.

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

#163064

On 09/10/2021 09:39, Malcolm McLean wrote:
> On Friday, 8 October 2021 at 22:52:21 UTC+1, Bart wrote:
>>
>> It depends on what its for. It you're developing an application then you
>> will need to build it 100 times a day or more. You might the ability to
>> do incremental compilation.
>>
>> But for a one-off build of some downloaded project, it will have to
>> compile everything from scratch anyway. Then it can be done much more
>> simply.
>>
> We  do an "integration build" whenever a unit of work is finished (we use JIRA
> and gitflow, a task is entered as a JIRA, a task branch is started, then it is merged
> into the develop branch when it is completed). Merging into the develop branch
> automatically triggers a complete re-build from scratch for all platforms.
> 
> This caught a problem yesterday. I had entered some data as long string literals.
> The compiler I was using accepted the strings. But one of the Windows compilers
> rejected them as too long.
> 

MSVC? That seems to have a 16K-char limit. You can get around it by 
splitting the strings into multiple ones (I think on different lines 
too), like "ABC" "DEF" instead of "ABCDEF".

Another way is to split with line continuation:

"ABC\
DEF"

The "\" can be inserted anywhere, even inside an escape sequence.

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web