Hi,

I noticed this menu option in the fpgui_toolkit.lpk package. So I selected it and made sure the “include” filter selects all files, and nothing is “excluded”. This clicked okay. After that I had a look in the destination directory, and there was only 9 file. Yet the fpgui_toolkit.lpk package actually has 117 files. See the screenshot showing the result (blue window) vs the actual package files.

So again, what is the function of “publish package”? It it is meant to copy all units from a package to a destination directory (*), it fails 'm using Lazarus 1.9.0 r54792 FPC 2.6.4 x86_64-freebsd-gtk2

* - Seems that is supposed to be its function, based on the wiki help page. But clearly it doesn't do a good job.
[http://wiki.lazarus.freepascal.org/IDE_Window:_Package_Editor#More]

Regards,
Graeme

The fpgui_toolkit directory only contains the 9 files. The other files are in parent or sibling directories.

It now checks if some unit/inc path are outside and disables the "publish" menu item.

I added a note of this limitation.

Mattias

Mattias Gaertner wrote

It copies the package directory with some options. The fpgui_toolkit directory only contains the 9 files. The other files are in parent or sibling directories.

But those are still part of the package. At you saying that when using "lazarus packages" you must (or should) always limit yourself to only one directory? Than seems a bit limiting.

I've also seen many projects where the project file and packages files are in the root directory of a project, and all source code are in sub directories. So all those are "wrong" too?

It now checks if some unit/inc path are outside and disables the "publish" menu item.

Fine with me, but it still seems like a useless feature then. Not actually being able to publish what is inside the package.

If it is making releases that one is after, it seems a much better solution is still (if you use git):

   $ git archive --prefix=prj-1.4.0/ -o prj-1.4.0.tar.gz v1.4.0

or

  $ git archive --output /full/path/to/zipfile.zip master

where "prj" is the name of the project. The last parameter is the commit, tag or branch you want to export.

I believe SubVersion's equivalent would be 'svn export ...' command.

Regards,
Graeme

No. Only the "publish package" function is limited.

It is useless for the fpgui package. That's why it is now disabled.

Not actually being able to publish what is inside the package.

What do you mean with "inside"?
It lists some units, but not all. Some directories are shared by other packages.
I see no straightforward rule to publish only the package fpgui_toolkit.

If it is making releases that one is after, it seems a much better solution is still (if you use git): $ git archive --prefix=prj-1.4.0/ -o prj-1.4.0.tar.gz v1.4.0

Huh? That is the whole fpgui, instead of just the fpgui_toolkit package.

Mattias

By "inside" I mean the files that are included in the original *.lpk package (what the Packages dialog shows). See the 114 files shown in the screenshot in the first message of this thread. That is the fpgui_toolkit.lpk Package Dialog - not simply a directory listing.

1) Also note that the published package unit "fpgui_toolkit.pas" (which states "Do not edit!") lists all the units of the fpgui_toolkit.lpk package, but they didn't exist in the published directory.

2) The published fpgui_toolkit.lpk also contains SearchPath entries. They were not modified from the original. Neither were the items in the Files tag.

So yeah, good you disabled that published option then, because the results were totally broken. ;-)

What could possibly work (but is more effort to implement) is to publish a package to a single directory (even if the original had multiple paths), but then the SearchPath and Files sections in the published .lpk file needs to be modified. So if somebody else opens that published package, all units are still found and is actually compilable. Just my 2c worth. But to be honest, I can't actually see a use for the "published package" functionality in the real world, so this could be chalked up as "no further action needed".

Regards,
Graeme