Hi all,

Seems like that after all these years there are still bugs in fpc's makefiles...

When you install a package, not the Package.fpc which is generated for the whole package, but the Package.fpc generated for the last sub-package is installed into
xxx/<version>/units/<target>/<packagename>.

Normally not really a problem, but fppkg uses these files to resolve dependencies. But the dependencies of the sub-package could be different from the dependencies of the main package.

Example: when you do 'make install' in fcl-web, a Package.fpc will be installed without the dependency on fcl-db. (In fact a Package.fpc made for jsonrpc is installed, which doesn't depend on fcl-db)

The result is that if you have fcl-web installed using fpcmake, and you want to install some other package using fpmake that depends on fcl-web, that will fail.

Shall I submit a bug-report for fpcmake with a request to use the proper Package.fpc file?

Joost.

No, in no case.

The whole idea of fppkg & fpmake is to get totally rid of fpcmake. Your proposal implies its continued use.

I think that fpmake should output the proper dependencies based on the dependencies specified in it. This output can be written to Package.fpc. (although I don't understand why it is in a Package.fpc, dependencies should be in the central package repository)

Michael.

I think we should.

The whole idea of fppkg & fpmake is to get totally rid of fpcmake. Your proposal implies its continued use.

We need it to make a smooth transition. As long as people have packages installed using the fpcmake-makefiles (which is as long as released fpc-versions still use this system, which bill be a long time...), we need this backward-compatibility.

I think that fpmake should output the proper dependencies based on the dependencies specified in it. This output can be written to Package.fpc. (although I don't understand why it is in a Package.fpc, dependencies should be in the central package repository)

If you use fpmake to install a package, a file named 'fpunits.conf' is created. In that case everything works.

But fpcmake creates a file named Package.cfg. When fpmake can't find a file named 'fpunits.conf', it searches and uses the Package.cfg file. If this file contains the wrong information, fpmake can't process the installed packages all right.

This is about installed packages, which maybe could not even exist in the central repository. The 'local' repository is nothing more than the sum of all fpunits.conf and Package.fpc files.

The problem I have now is that I want to add package that depends in fcl-web. Most users have fcl-web installed using the fpcmake-system. (That's after all what we use by default) When you try to install this package depending on fcl-web, it won't detect the dependency on fcl-db, since the Package.fpc from fcl-web is invalid. So you can't build this new package.

So as long as this problem isn't fixed in fpcmake, we can't use fpmake for packages which are installed using fpcmake. Iow: we can't make package which have dependencies on any package which comes with Free Pascal. (As long as we don't switch to fpmake entirely)

So in principle your statement is right: fixing this will lead to a (long) period that both systems can be used at the same time. But I doubt that forcing a transition at once, will lead to a faster acceptance of fpmake. ;)

Joost

If handled right, I don't see why not.
I doubt many users are aware of the Package.fpc and fpcmake.

But since you'll be doing the work, who am I to complain ? :-)

Michael.

Yeah, well, on second thought. Maybe you're right. See what happens if I change the makefile from one package...

But since you'll be doing the work, who am I to complain ? :-)

Well, in this case you would have to help me fixing fpcmake. But I'll try to go for the big bang.

Joost.

I'll be glad to test things for you with fpmake/fppkg, just give me specific things you want tested.

Michael.