Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2006-10

Makefiles vs Pascal Automation

5 messages · 3 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

L505

In many cases makefiles take about just as long to create as shell scripts or pascal programs - they just offer a nice framework to automate compiling in an easy way - but in sort of a funny syntax. But makefiles kind of become ugly when they get big - and because they have a poor syntax compared to pascal programs - couldn't one just write a pascal program to automate the compilation process, instead of a makefile? (if a good framework was in place).

A reusable "automation" unit or framework would need to be created so that automating the compile process from within a pascal program was easy.

After thinking about it, I determined that makefiles are actually PROGRAMS in disguise - not config files, as their syntax seems to lead us to believe. They are config files on steroids. Config files generally don't execute instructions.. config files are more geared toward storage of settings. But makefiles do execute instructions! Makefiles are programs, not settings files.

So if makefiles are actually mini-programs, why couldn't we simply write makefiles in pascal instead of writing makefiles in makefile-language/fpcmake-language?

Psuedo Example.. let's consider I have to make four CGI programs in one shot. I want to rename EXE or ELF programs to CGI programs after the compilation is done. Compiling four programs using Make is possible, writing up a makefile.. but it could also be done this way:

program Maker;
uses
  CompileTools; //the framework that simulates MAKE
const
  targets : array of [1..4] = ('index.pp', 'main.pp', 'login.pp', 'logout.pp');
begin
  // compile several programs
  Compile(targets);
  if OStarget = linux then
     writeln('compiling 4 programs for linux..');
  // 4 could actually be "CompileCount", if framework implemented such a thing
  if OStarget = windows then
     writeln('compiling 4 programs for windows..');
  for i:= 1 to 4 do
   RenameFile(CompiledEXE[i], CompiledEXEName[i] + '.cgi');
  DeleteFiles('*.ppu', '*.a', '*.o');
end;

At the command line:
maker all

Instead of using make:
make all

The framework in the maker program would handle "all", "clean", etc. Instead of writing a new makefile each time we wanted to automated compilation, we would simple write a new pascal program which used the maker framework.

Why did I come across this idea? The same reason I sometimes build a pascal program instead of using a shell script!
The same reason that HTML files would make poor executables! The same reason that config files are really not meant to be programs... but rather settings files. Similarly, a config file is really not a program - and makefiles are becoming INI files on steroids - programs!

If compiling the MAKER program each time is too much work, then maybe this would be a good use for PascalScript.

So basically my main point is that make files have become executable INI files - something INI files really aren't intended to be - with less power and clarity than a real pascal program.

Mattias Gaertner
to L505
Show quoted text 70 lines
In many cases makefiles take about just as long to create as shell scripts or pascal programs - they just offer a nice framework to automate compiling in an easy way - but in sort of a funny syntax. But makefiles kind of become ugly when they get big - and because they have a poor syntax compared to pascal programs - couldn't one just write a pascal program to automate the compilation process, instead of a makefile? (if a good framework was in place). A reusable "automation" unit or framework would need to be created so that automating the compile process from within a pascal program was easy. After thinking about it, I determined that makefiles are actually PROGRAMS in disguise - not config files, as their syntax seems to lead us to believe. They are config files on steroids. Config files generally don't execute instructions.. config files are more geared toward storage of settings. But makefiles do execute instructions! Makefiles are programs, not settings files. So if makefiles are actually mini-programs, why couldn't we simply write makefiles in pascal instead of writing makefiles in makefile-language/fpcmake-language? Psuedo Example.. let's consider I have to make four CGI programs in one shot. I want to rename EXE or ELF programs to CGI programs after the compilation is done. Compiling four programs using Make is possible, writing up a makefile.. but it could also be done this way: program Maker; uses CompileTools; //the framework that simulates MAKE const targets : array of [1..4] = ('index.pp', 'main.pp', 'login.pp', 'logout.pp'); begin // compile several programs Compile(targets); if OStarget = linux then writeln('compiling 4 programs for linux..'); // 4 could actually be "CompileCount", if framework implemented such a thing if OStarget = windows then writeln('compiling 4 programs for windows..'); for i:= 1 to 4 do RenameFile(CompiledEXE[i], CompiledEXEName[i] + '.cgi'); DeleteFiles('*.ppu', '*.a', '*.o'); end; At the command line: maker all Instead of using make: make all The framework in the maker program would handle "all", "clean", etc. Instead of writing a new makefile each time we wanted to automated compilation, we would simple write a new pascal program which used the maker framework. Why did I come across this idea? The same reason I sometimes build a pascal program instead of using a shell script! The same reason that HTML files would make poor executables! The same reason that config files are really not meant to be programs... but rather settings files. Similarly, a config file is really not a program - and makefiles are becoming INI files on steroids - programs! If compiling the MAKER program each time is too much work, then maybe this would be a good use for PascalScript. So basically my main point is that make files have become executable INI files - something INI files really aren't intended to be - with less power and clarity than a real pascal program.

That's why FPC is switching to fpmake.pp files. And eventually/probably lazarus too.

Mattias

L505
to Mattias Gaertner
Show quoted text 6 lines
> So basically my main point is that make files have become executable > INI files - something INI files really aren't intended to be - with > less power and clarity than a real pascal program. That's why FPC is switching to fpmake.pp files. And eventually/probably lazarus too.

Ohh.. I didn't hear about it yet.

Michael Van Canneyt
to L505
L505 wrote 10 lines
> > So basically my main point is that make files have become executable > > INI files - something INI files really aren't intended to be - with > > less power and clarity than a real pascal program. > > That's why FPC is switching to fpmake.pp files. And eventually/probably > lazarus too. Ohh.. I didn't hear about it yet.

check out the fpmake.pp and fpmake.inc file scattered all over the source trees; and the sources in utils/fppkg do what you describe 'TInstaller' TBuildEngine etc.

We are working on a 2-stage approach:

fpmake:
compile/install/zip one or more packages (loosely defined as a group of units) fppkg:
package manager like smart/yum/yast/rpm with download capacity.

fpmake works already. fppkg is under construction.

We'll base the 2.2 release on it, if all goes according to plan.

Michael.

L505
to Michael Van Canneyt
Show quoted text 17 lines
check out the fpmake.pp and fpmake.inc file scattered all over the source trees; and the sources in utils/fppkg do what you describe 'TInstaller' TBuildEngine etc. We are working on a 2-stage approach: fpmake: compile/install/zip one or more packages (loosely defined as a group of units) fppkg: package manager like smart/yum/yast/rpm with download capacity. fpmake works already. fppkg is under construction. We'll base the 2.2 release on it, if all goes according to plan. Michael.

Ahh.. I thought maybe I was nuts for thinking up such a thing - and I needed verification that developers think alike ;-) It's too bad I spent so much time thinking about how to implement a psuedo example it when it is already in the works.