Sign in Join

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

Mailing lists / fpc-devel / 2007-08

fpmake listsources

8 messages · 4 people · –

Reply by email Subscribe to this list Your subscription

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

Darius Blaszijk

While looking at the listsources command I found something peculiar (i think).

The method TPackage.GetSourceFiles lists all sources stored in TSources. This seems to be strange for two reasons

1) all sources are stored in TTarget
2) the sources variable in TPackage is never filled automatically when you add units or programs from fpmake.pp, which would indicate the user has to fill the variable himself, but this defies the listsources command.

This leads me to believe TSources is an artifact from the past. Is that correct?

I would propose to change the implementation in TPackage.GetSourceFiles so it retrieves sources from TTarget instead and then remove TSources altogether.

Oh yes, what is the actual planned purpose of listsources ;) ? Is it something similar to maven verify? In that case I would like to propose to additionally list the results of all commands plus some checks. I will give a more detailed example if needed.

Darius

Reply by email

Peter Vreman
to Darius Blaszijk
you wrote 22 lines
While looking at the listsources command I found something peculiar (i think). The method TPackage.GetSourceFiles lists all sources stored in TSources. This seems to be strange for two reasons 1) all sources are stored in TTarget 2) the sources variable in TPackage is never filled automatically when you add units or programs from fpmake.pp, which would indicate the user has to fill the variable himself, but this defies the listsources command. This leads me to believe TSources is an artifact from the past. Is that correct? I would propose to change the implementation in TPackage.GetSourceFiles so it retrieves sources from TTarget instead and then remove TSources altogether. Oh yes, what is the actual planned purpose of listsources ;) ? Is it something similar to maven verify? In that case I would like to propose to additionally list the results of all commands plus some checks. I will give a more detailed example if needed.

This is exactly the point were development of fppkg/fpmake stalled.

There needs to be a xml file generated either in sources.xml or manifest.xml that can be used by fppkg to create an archive out of it.

Using TTarget for sources is a bit complex because you can have include files and also implicitly build units that also depend on include files and depending on the target different source directories. Also how to handle additional input data files that are convert to typedconstant-includefiles. Therefor i had the idea to add a TSources that can list complete directories.

There is no final decision made yet. Ideas how to implement it nicely are welcome.

I'll be on holiday the next week so i won't be able to comment on ideas.

Peter

Reply by email

Michael Van Canneyt
to Darius Blaszijk: While looking at the listsources command I found something peculiar (i think). The method…
Darius Blaszijk wrote 12 lines
While looking at the listsources command I found something peculiar (i think). The method TPackage.GetSourceFiles lists all sources stored in TSources. This seems to be strange for two reasons 1) all sources are stored in TTarget 2) the sources variable in TPackage is never filled automatically when you add units or programs from fpmake.pp, which would indicate the user has to fill the variable himself, but this defies the listsources command. This leads me to believe TSources is an artifact from the past. Is that correct?

I rather assume the opposite.

I would propose to change the implementation in TPackage.GetSourceFiles so it retrieves sources from TTarget instead and then remove TSources altogether.

Yes.

Show quoted text 5 lines
Oh yes, what is the actual planned purpose of listsources ;) ? Is it something similar to maven verify? In that case I would like to propose to additionally list the results of all commands plus some checks. I will give a more detailed example if needed.

The purpose is to create a source zipfile.

Michael.

Reply by email

Michael Van Canneyt
to Peter Vreman: This is exactly the point were development of fppkg/fpmake stalled. There needs to be a…
Peter Vreman wrote 24 lines
At 19:35 16-8-2007, you wrote: >While looking at the listsources command I found something peculiar (i >think). > >The method TPackage.GetSourceFiles lists all sources stored in TSources. This >seems to be strange for two reasons > >1) all sources are stored in TTarget >2) the sources variable in TPackage is never filled automatically when you >add units or programs from fpmake.pp, which would indicate the user has to >fill the variable himself, but this defies the listsources command. > >This leads me to believe TSources is an artifact from the past. Is that >correct? > >I would propose to change the implementation in TPackage.GetSourceFiles so it >retrieves sources from TTarget instead and then remove TSources altogether. > >Oh yes, what is the actual planned purpose of listsources ;) ? Is it >something similar to maven verify? In that case I would like to propose to >additionally list the results of all commands plus some checks. I will give a >more detailed example if needed. This is exactly the point were development of fppkg/fpmake stalled.

Proving my statement that sources was added at a later point, since I didn't include it initially :-)

Show quoted text 9 lines
There needs to be a xml file generated either in sources.xml or manifest.xml that can be used by fppkg to create an archive out of it. Using TTarget for sources is a bit complex because you can have include files and also implicitly build units that also depend on include files and depending on the target different source directories. Also how to handle additional input data files that are convert to typedconstant-includefiles. Therefor i had the idea to add a TSources that can list complete directories.

That seems a bit overkill. I would add some commands that can be used to fill up sources.

AddSources('*.pp')
AddSource('somesource.pas');
AddSource('somefile.ini');
Show quoted text 5 lines
There is no final decision made yet. Ideas how to implement it nicely are welcome. I'll be on holiday the next week so i won't be able to comment on ideas.

I am not on holiday, so I am available for comments :-)

Michael.

Reply by email

Darius Blaszijk
to Michael Van Canneyt
Michael Van Canneyt wrote 37 lines
On Thu, 16 Aug 2007, Peter Vreman wrote: > At 19:35 16-8-2007, you wrote: > >> While looking at the listsources command I found something peculiar (i >> think). >> >> The method TPackage.GetSourceFiles lists all sources stored in TSources. This >> seems to be strange for two reasons >> >> 1) all sources are stored in TTarget >> 2) the sources variable in TPackage is never filled automatically when you >> add units or programs from fpmake.pp, which would indicate the user has to >> fill the variable himself, but this defies the listsources command. >> >> This leads me to believe TSources is an artifact from the past. Is that >> correct? >> >> I would propose to change the implementation in TPackage.GetSourceFiles so it >> retrieves sources from TTarget instead and then remove TSources altogether. >> >> Oh yes, what is the actual planned purpose of listsources ;) ? Is it >> something similar to maven verify? In that case I would like to propose to >> additionally list the results of all commands plus some checks. I will give a >> more detailed example if needed. >> > This is exactly the point were development of fppkg/fpmake stalled. > Proving my statement that sources was added at a later point, since I didn't include it initially :-) > There needs to be a xml file generated either in sources.xml or manifest.xml > that can be used by fppkg to create an archive out of it. >

So what is the function of archive then? This command already lists all source files in the package. Only thing to do is to implement zipfile creation.

Show quoted text 14 lines
> Using TTarget for sources is a bit complex because you can have include files > and also implicitly build units that also depend on include files and > depending on the target different source directories. Also how to handle > additional input data files that are convert to typedconstant-includefiles. > Therefor i had the idea to add a TSources that can list complete directories. > That seems a bit overkill. I would add some commands that can be used to fill up sources. AddSources('*.pp') AddSource('somesource.pas'); AddSource('somefile.ini');

Cannot agree more.

Show quoted text 8 lines
> There is no final decision made yet. Ideas how to implement it nicely are > welcome. > > I'll be on holiday the next week so i won't be able to comment on ideas. > I am not on holiday, so I am available for comments :-)

Great! I have a lot of questions :)

Darius

Reply by email

Darius Blaszijk
to Darius Blaszijk
So, to list everything on the package creation;

Can we have fpmake to create the individual packages, or does fppkg need to be fed with a list of sources per package and package them. I would prefer the first as it will keep the code more clean and will give other users of fpmake the ability to create source packages, independent of fppkg. Fppkg should call archive (or better call it package) instead of listsources.

I will also expose the TSources methods AddDocFiles, AddSrcFiles, AddExampleFiles and AddTestFiles in TPackage and add these files in the archiving process (will have to make sure I don't add files double).

If that's ok with everyone ;)

Darius

Reply by email

Michael Van Canneyt
to Darius Blaszijk
Darius Blaszijk wrote 7 lines
So, to list everything on the package creation; Can we have fpmake to create the individual packages, or does fppkg need to be fed with a list of sources per package and package them. I would prefer the first as it will keep the code more clean and will give other users of fpmake the ability to create source packages, independent of fppkg. Fppkg should call archive (or better call it package) instead of listsources.

There are 2 sides to this question:

I think if we want to use fpmake outside strict FPC-related stuff, then it's better to have the archiving inside fpmake. So then we must go for that option. This was also my original idea when implementing it.

The problem with this - Peter Vreman pointed this out - is bootstrapping: If FPC is ported to a new platform, it means that to compile fpmake, TZipper should compile, and that in turn means that a whole lot of other stuff should compile as well. This is why it was decided to move the archiving to fppkg.

Therefor, my proposal is the following: Both should be able to do archiving.

in fpmkunit, the TZipper support should be in an {$IFNDEF EXTERNALZIP}, the alternative should be calling a regular zip application. The EXTERNALZIP can be defined when porting to a new platform.

In fppkg, TZipper support can be included by default. The list of files should be retrieved from fpmake, which needs this list anyway.

Show quoted text 6 lines
I will also expose the TSources methods AddDocFiles, AddSrcFiles, AddExampleFiles and AddTestFiles in TPackage and add these files in the archiving process (will have to make sure I don't add files double). If that's ok with everyone ;)

Perfectly OK !

Michael.

Reply by email

Unknown author
to Michael Van Canneyt
Show quoted text 46 lines
On Sat, 18 Aug 2007, Darius Blaszijk wrote: > So, to list everything on the package creation; > > Can we have fpmake to create the individual packages, or does fppkg need > to be > fed with a list of sources per package and package them. I would prefer > the > first as it will keep the code more clean and will give other users of > fpmake > the ability to create source packages, independent of fppkg. Fppkg > should call > archive (or better call it package) instead of listsources. There are 2 sides to this question: I think if we want to use fpmake outside strict FPC-related stuff, then it's better to have the archiving inside fpmake. So then we must go for that option. This was also my original idea when implementing it. The problem with this - Peter Vreman pointed this out - is bootstrapping: If FPC is ported to a new platform, it means that to compile fpmake, TZipper should compile, and that in turn means that a whole lot of other stuff should compile as well. This is why it was decided to move the archiving to fppkg. Therefor, my proposal is the following: Both should be able to do archiving. in fpmkunit, the TZipper support should be in an {$IFNDEF EXTERNALZIP}, the alternative should be calling a regular zip application. The EXTERNALZIP can be defined when porting to a new platform. In fppkg, TZipper support can be included by default. The list of files should be retrieved from fpmake, which needs this list anyway. > > I will also expose the TSources methods AddDocFiles, AddSrcFiles, > AddExampleFiles and AddTestFiles in TPackage and add these files in the > archiving process (will have to make sure I don't add files double). > > If that's ok with everyone ;) Perfectly OK !

So it shall be done.

Darius

Reply by email