fpmake: output directories

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

fpmake: output directories

Mattias Gaertner
Hi fpmake devels,

fpmake uses as ppu output directory for example:
units/i386-linux/
And there is no way to change this. Right?

Some LCL packages have different PPUs per widgetset, so they need an
output directory per widgetset. At the moment they use for example:
units/i386-linux-gtk2/
Another example is to distinguish between release and debug version.

What is the best/recommended way to solve this with fpmake?


Mattias

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: fpmake: output directories

Michael Van Canneyt


On Mon, 1 Jun 2009, Mattias Gaertner wrote:

> Hi fpmake devels,
>
> fpmake uses as ppu output directory for example:
> units/i386-linux/
> And there is no way to change this. Right?
>
> Some LCL packages have different PPUs per widgetset, so they need an
> output directory per widgetset. At the moment they use for example:
> units/i386-linux-gtk2/
> Another example is to distinguish between release and debug version.
>
> What is the best/recommended way to solve this with fpmake?

You can't in this way.

The problem is the dependencies. The build system must know where the
units are for every package, so this is packagename/units/CPU-OS/

You must make different packages per widgetset. They can be generated
by the same fpmake.
That means that you must make a package lcl-gtk2, which then is
installed in
lcl-gtk2/units/linux-gtk2/

That should cover your needs ?

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: fpmake: output directories

Vincent Snijders-2
Michael Van Canneyt schreef:

>
>
> On Mon, 1 Jun 2009, Mattias Gaertner wrote:
>
>> Hi fpmake devels,
>>
>> fpmake uses as ppu output directory for example:
>> units/i386-linux/
>> And there is no way to change this. Right?
>>
>> Some LCL packages have different PPUs per widgetset, so they need an
>> output directory per widgetset. At the moment they use for example:
>> units/i386-linux-gtk2/
>> Another example is to distinguish between release and debug version.
>>
>> What is the best/recommended way to solve this with fpmake?
>
> You can't in this way.

So, no debug and release version on one computer?

>
> The problem is the dependencies. The build system must know where the
> units are for every package, so this is packagename/units/CPU-OS/
>
> You must make different packages per widgetset. They can be generated
> by the same fpmake.
> That means that you must make a package lcl-gtk2, which then is
> installed in
> lcl-gtk2/units/linux-gtk2/
>
typo?
lcl-gtk2/units/i386-linux/

Vincent
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: fpmake: output directories

Michael Van Canneyt


On Tue, 2 Jun 2009, Vincent Snijders wrote:

> Michael Van Canneyt schreef:
>>
>>
>> On Mon, 1 Jun 2009, Mattias Gaertner wrote:
>>
>>> Hi fpmake devels,
>>>
>>> fpmake uses as ppu output directory for example:
>>> units/i386-linux/
>>> And there is no way to change this. Right?
>>>
>>> Some LCL packages have different PPUs per widgetset, so they need an
>>> output directory per widgetset. At the moment they use for example:
>>> units/i386-linux-gtk2/
>>> Another example is to distinguish between release and debug version.
>>>
>>> What is the best/recommended way to solve this with fpmake?
>>
>> You can't in this way.
>
> So, no debug and release version on one computer?

Not in this way, at least.

Don't forget that the system is geared towards *installing* the units in
a directory. As far as I can see, this is never done with lazarus. The
compiled units always reside in the lazarus source tree.

I have asked the question once: How to have 2 lazarus unit trees,
(e.g. produced by 2 compilers, or debug and not-debug)
but I never got an answer.

for fpmake I envisaged a system
/somefpcdir/packagename/units/i386-linux
and then a debug version in
/somefpcdir/debug/packagename/units/i386-linux

Or something similar. But nothing is fixed yet.

>> The problem is the dependencies. The build system must know where the units
>> are for every package, so this is packagename/units/CPU-OS/
>>
>> You must make different packages per widgetset. They can be generated
>> by the same fpmake.
>> That means that you must make a package lcl-gtk2, which then is installed
>> in
>> lcl-gtk2/units/linux-gtk2/
>>
> typo?
> lcl-gtk2/units/i386-linux/

Yes, sorry :(

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: fpmake: output directories

Michael Van Canneyt


On Tue, 2 Jun 2009, Michael Van Canneyt wrote:

>
>
> On Tue, 2 Jun 2009, Vincent Snijders wrote:
>
>> Michael Van Canneyt schreef:
>>>
>>>
>>> On Mon, 1 Jun 2009, Mattias Gaertner wrote:
>>>
>>>> Hi fpmake devels,
>>>>
>>>> fpmake uses as ppu output directory for example:
>>>> units/i386-linux/
>>>> And there is no way to change this. Right?
>>>>
>>>> Some LCL packages have different PPUs per widgetset, so they need an
>>>> output directory per widgetset. At the moment they use for example:
>>>> units/i386-linux-gtk2/
>>>> Another example is to distinguish between release and debug version.
>>>>
>>>> What is the best/recommended way to solve this with fpmake?
>>>
>>> You can't in this way.
>>
>> So, no debug and release version on one computer?
>
> Not in this way, at least.

Hi,

Peter Vreman reminded me that we had this discussion on core about a year
ago. The solution we came up with was a 'subtarget' or 'configuration'.

This was simply an option to fpmake, which would alter the output path and
search paths. It was needed to discern between debug and non-debug, PIC and
non-PIC code etc.

So there would be

fpmake --subtarget=debug

Which would send output in

units/i386-linux-debug

So maybe this can be used for the widgetsets, debug-non debug etc.

Beware: AFAIK it has not yet been implemented, but that was the initial
idea.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: fpmake: output directories

Mattias Gaertner
Zitat von Michael Van Canneyt <[hidden email]>:

>
>
> On Tue, 2 Jun 2009, Michael Van Canneyt wrote:
>
>>
>>
>> On Tue, 2 Jun 2009, Vincent Snijders wrote:
>>
>>> Michael Van Canneyt schreef:
>>>>
>>>>
>>>> On Mon, 1 Jun 2009, Mattias Gaertner wrote:
>>>>
>>>>> Hi fpmake devels,
>>>>>
>>>>> fpmake uses as ppu output directory for example:
>>>>> units/i386-linux/
>>>>> And there is no way to change this. Right?
>>>>>
>>>>> Some LCL packages have different PPUs per widgetset, so they need an
>>>>> output directory per widgetset. At the moment they use for example:
>>>>> units/i386-linux-gtk2/
>>>>> Another example is to distinguish between release and debug version.
>>>>>
>>>>> What is the best/recommended way to solve this with fpmake?
>>>>
>>>> You can't in this way.
>>>
>>> So, no debug and release version on one computer?
>>
>> Not in this way, at least.
>
> Hi,
>
> Peter Vreman reminded me that we had this discussion on core about a year
> ago. The solution we came up with was a 'subtarget' or 'configuration'.
>
> This was simply an option to fpmake, which would alter the output path and
> search paths. It was needed to discern between debug and non-debug,  
> PIC and non-PIC code etc.
>
> So there would be
>
> fpmake --subtarget=debug
>
> Which would send output in
>
> units/i386-linux-debug
>
> So maybe this can be used for the widgetsets, debug-non debug etc.
>
> Beware: AFAIK it has not yet been implemented, but that was the initial
> idea.

Thanks.
Maybe this can be used for debug/release.
I don't see how this can be used for the widgetsets.

My dream is this:
User opens a project and/or package and the IDE uses fppkg to download  
and install automatically the missing packages.
Some packages like the LCL are already installed via lazarus. So  
somehow fppkg needs to know, that some packages don't need be  
downloaded from the repositories. Maybe lazarus can register a local  
repository?


Mattias

--
Powered by NetMail

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: fpmake: output directories

Michael Van Canneyt


On Tue, 2 Jun 2009, Mattias Gärtner wrote:

> Zitat von Michael Van Canneyt <[hidden email]>:
>
>>
>>
>> On Tue, 2 Jun 2009, Michael Van Canneyt wrote:
>>
>>>
>>>
>>> On Tue, 2 Jun 2009, Vincent Snijders wrote:
>>>
>>>> Michael Van Canneyt schreef:
>>>>>
>>>>>
>>>>> On Mon, 1 Jun 2009, Mattias Gaertner wrote:
>>>>>
>>>>>> Hi fpmake devels,
>>>>>>
>>>>>> fpmake uses as ppu output directory for example:
>>>>>> units/i386-linux/
>>>>>> And there is no way to change this. Right?
>>>>>>
>>>>>> Some LCL packages have different PPUs per widgetset, so they need an
>>>>>> output directory per widgetset. At the moment they use for example:
>>>>>> units/i386-linux-gtk2/
>>>>>> Another example is to distinguish between release and debug version.
>>>>>>
>>>>>> What is the best/recommended way to solve this with fpmake?
>>>>>
>>>>> You can't in this way.
>>>>
>>>> So, no debug and release version on one computer?
>>>
>>> Not in this way, at least.
>>
>> Hi,
>>
>> Peter Vreman reminded me that we had this discussion on core about a year
>> ago. The solution we came up with was a 'subtarget' or 'configuration'.
>>
>> This was simply an option to fpmake, which would alter the output path and
>> search paths. It was needed to discern between debug and non-debug, PIC and
>> non-PIC code etc.
>>
>> So there would be
>>
>> fpmake --subtarget=debug
>>
>> Which would send output in
>>
>> units/i386-linux-debug
>>
>> So maybe this can be used for the widgetsets, debug-non debug etc.
>>
>> Beware: AFAIK it has not yet been implemented, but that was the initial
>> idea.
>
> Thanks.
> Maybe this can be used for debug/release.
> I don't see how this can be used for the widgetsets.
Why not ? you can use
  subtarget=gtk2-debug

>
> My dream is this:
> User opens a project and/or package and the IDE uses fppkg to download and
> install automatically the missing packages.
> Some packages like the LCL are already installed via lazarus. So somehow
> fppkg needs to know, that some packages don't need be downloaded from the
> repositories. Maybe lazarus can register a local repository?

fppkg will see what is installed locally, and will not download what is
already there (unless the versions don't match).

The point is that the LCL must be installed in the package system, so fppkg
knows about it. That means an additional copy operation.

If you don't want that, then we must see about 'registering' local
build trees in fppkg; By this I mean that fppkg assumes that all is
installed under

~user/.fppkg/build/

(or something like it)

if you don't want this, you should be able to tell it that it should also look in
e.g.

/path/to/lazarusdir/components/

To find additional packages there.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: fpmake: output directories

Graeme Geldenhuys-2
2009/6/2 Michael Van Canneyt <[hidden email]>:
>
> ~user/.fppkg/build/
>
> (or something like it)


Possibly the $HOME/.local/ directory.  I have the following structure
in there, but I tried to find out on freedesktop.org or linux
standands what is recommend regarding the ~/.local/ directory, but I
couldn't find any documentation on it.

Either way, I don't think ~/.config/ is the right place, nor the
~/.fppkg/ directory. Just my opinion. ;-)

=====================
/home/graemeg/.local
   .
   |-share
   |---applications
   |-----wine
   |-------Programs
   |---------Datanamic
   |---------HelpScribble
   |-----------Sample Project
   |---desktop-directories
   |---icons
   |---tracker
   |-----data
   |---Trash
   |-----files
   |-----info
=====================


Regards,
  - Graeme -


_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: fpmake: output directories

Michael Van Canneyt


On Tue, 2 Jun 2009, Graeme Geldenhuys wrote:

> 2009/6/2 Michael Van Canneyt <[hidden email]>:
>>
>> ~user/.fppkg/build/
>>
>> (or something like it)
>
>
> Possibly the $HOME/.local/ directory.  I have the following structure
> in there, but I tried to find out on freedesktop.org or linux
> standands what is recommend regarding the ~/.local/ directory, but I
> couldn't find any documentation on it.

What is the .local directory ? I don't have one, and I never heard of it.
If it is again a so-called standard by freedesktop, then it's a nono.

I still haven't recovered from the mistake to put everything below
'.config', also a 'standard' by freedesktop, implemented in sysutils :(

So .fppkg it is by default, and it remains so. Good old unix custom.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: fpmake: output directories

Graeme Geldenhuys-2
2009/6/2 Michael Van Canneyt <[hidden email]>:
>
> What is the .local directory ? I don't have one, and I never heard of it.
> If it is again a so-called standard by freedesktop, then it's a nono.

I don't know, and like I mentioned, I tried to Google it, to see who
decided on the ~/.local/ and what everything is supposed to go in
there.

As far as I can see, Kunbuntu and Ubuntu desktops use in for the Trash
can (delete files get moved to ~/.local/share/Trash/files/ directory.
WINE also seems to use it, and some applications install there icons
into ~/.local/share/icons.

Like I said, no idea if it's a "standard", but there are definitely a
few unrelated software projects using it.

> I still haven't recovered from the mistake to put everything below
> '.config', also a 'standard' by freedesktop, implemented in sysutils :(

For configuration files, I love the .config directory. :-)  [Sorry Michael]


> So .fppkg it is by default, and it remains so. Good old unix custom.

No complaints here, just thought I would mention the "dot" directories
I have in my $HOME.


Regards,
  - Graeme -


_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: fpmake: output directories

Peter Vreman
In reply to this post by Mattias Gaertner
Mattias Gärtner wrote:

> Zitat von Michael Van Canneyt <[hidden email]>:
>
>>
>>
>> On Tue, 2 Jun 2009, Michael Van Canneyt wrote:
>>
>>>
>>>
>>> On Tue, 2 Jun 2009, Vincent Snijders wrote:
>>>
>>>> Michael Van Canneyt schreef:
>>>>>
>>>>>
>>>>> On Mon, 1 Jun 2009, Mattias Gaertner wrote:
>>>>>
>>>>>> Hi fpmake devels,
>>>>>>
>>>>>> fpmake uses as ppu output directory for example:
>>>>>> units/i386-linux/
>>>>>> And there is no way to change this. Right?
>>>>>>
>>>>>> Some LCL packages have different PPUs per widgetset, so they need an
>>>>>> output directory per widgetset. At the moment they use for example:
>>>>>> units/i386-linux-gtk2/
>>>>>> Another example is to distinguish between release and debug version.
>>>>>>
>>>>>> What is the best/recommended way to solve this with fpmake?
>>>>>
>>>>> You can't in this way.
>>>>
>>>> So, no debug and release version on one computer?
>>>
>>> Not in this way, at least.
>>
>> Hi,
>>
>> Peter Vreman reminded me that we had this discussion on core about a year
>> ago. The solution we came up with was a 'subtarget' or 'configuration'.
>>
>> This was simply an option to fpmake, which would alter the output path
>> and
>> search paths. It was needed to discern between debug and non-debug,
>> PIC and non-PIC code etc.
>>
>> So there would be
>>
>> fpmake --subtarget=debug
>>
>> Which would send output in
>>
>> units/i386-linux-debug
>>
>> So maybe this can be used for the widgetsets, debug-non debug etc.
>>
>> Beware: AFAIK it has not yet been implemented, but that was the initial
>> idea.
>
> Thanks.
> Maybe this can be used for debug/release.
> I don't see how this can be used for the widgetsets.
>
> My dream is this:
> User opens a project and/or package and the IDE uses fppkg to download
> and install automatically the missing packages.
> Some packages like the LCL are already installed via lazarus. So somehow
> fppkg needs to know, that some packages don't need be downloaded from
> the repositories. Maybe lazarus can register a local repository?

fppkg works with different compiler configuration files stored in
~/.fppkg/config/. The default file for the current target is called
'default'. This file is implicitly created at first start. Additional
configuration files can be created manually. These configuration files
can contain cross-compile settings, e.g. a file 'win32' can be created
having 'os=win32'. fppkg can then be called with 'fppkg --config=win32'
to cross compile and install for i386-win32.

What still has to be done is extending this small configuration file
with 2 new settings: 'CompilerOptions' and 'DirectorySuffix'. These can
then be used to create release and debug configurations:

release:
CompilerOptions=-O3 -CX -XX
DirectorySuffix=release

debug:
CompilerOptions=-O- -gwl
DirectorySuffix=debug

For i386-linux then the release will then output in
'units/i386-linux-release/<packagename>/' and the debug will goto
'units/i386-linux-debug/<packagename>/'

The same can be done for lazarus widgetsets:

gtk2:
CompilerOptions=-O3 -CX -XX -dGTK2
DirectorySuffix=gtk2

There is currently another limitation in fppkg: There is only one single
LocalUnitDir and GlobalUnitDir. This might to be enhanced to support
multiple directories at least for searching installed packages in a
dedicated lazarus repository. Also to support multiple configuration
suffixes so that the units/i386-linux/rtl can be used together with
units/i386-linux-gtk2/lcl.


Peter
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: fpmake: output directories

Giuliano Colla
In reply to this post by Michael Van Canneyt
Michael Van Canneyt ha scritto:

>
>
> On Tue, 2 Jun 2009, Graeme Geldenhuys wrote:
>
>> 2009/6/2 Michael Van Canneyt <[hidden email]>:
>>>
>>> ~user/.fppkg/build/
>>>
>>> (or something like it)
>>
>>
>> Possibly the $HOME/.local/ directory.  I have the following structure
>> in there, but I tried to find out on freedesktop.org or linux
>> standands what is recommend regarding the ~/.local/ directory, but I
>> couldn't find any documentation on it.
>
> What is the .local directory ? I don't have one, and I never heard of it.
> If it is again a so-called standard by freedesktop, then it's a nono.
>
Sorry, but $HOME/.local IS a so-called standard by freedesktop:

http://standards.freedesktop.org/basedir-spec/latest/ar01s03.html

States that user specific data files should be stored in a directory
which defaults to $HOME/.local/share :-( (as opposed to user specific
configuration files which should go into $HOME/.config). But one must be
careful to tell apart essential from non-essential data files, because
user specific non-essential data files should be stored in $HOME/.cache.
I gather from the above that user specific useless data files should be
stored in $HOME/.shit (if not otherwise specified in $XDG_SHIT_HOME). ;-)
It appears that they're facing the mission of "avoiding the $HOME
directory cluttered by dot files" (as stated somewhere else), by the
clever device of adding more dot files.
> So .fppkg it is by default, and it remains so. Good old unix custom.
>
Avery wise choice.

Giuliano

_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: fpmake: output directories

Michael Van Canneyt


On Wed, 3 Jun 2009, Giuliano Colla wrote:

> Michael Van Canneyt ha scritto:
>>
>>
>> On Tue, 2 Jun 2009, Graeme Geldenhuys wrote:
>>
>>> 2009/6/2 Michael Van Canneyt <[hidden email]>:
>>>>
>>>> ~user/.fppkg/build/
>>>>
>>>> (or something like it)
>>>
>>>
>>> Possibly the $HOME/.local/ directory.  I have the following structure
>>> in there, but I tried to find out on freedesktop.org or linux
>>> standands what is recommend regarding the ~/.local/ directory, but I
>>> couldn't find any documentation on it.
>>
>> What is the .local directory ? I don't have one, and I never heard of it.
>> If it is again a so-called standard by freedesktop, then it's a nono.
>>
> Sorry, but $HOME/.local IS a so-called standard by freedesktop:
>
> http://standards.freedesktop.org/basedir-spec/latest/ar01s03.html
>
> States that user specific data files should be stored in a directory which
> defaults to $HOME/.local/share :-( (as opposed to user specific configuration
> files which should go into $HOME/.config). But one must be careful to tell
> apart essential from non-essential data files, because user specific
> non-essential data files should be stored in $HOME/.cache.
> I gather from the above that user specific useless data files should be
> stored in $HOME/.shit (if not otherwise specified in $XDG_SHIT_HOME). ;-)
> It appears that they're facing the mission of "avoiding the $HOME directory
> cluttered by dot files" (as stated somewhere else), by the clever device of
> adding more dot files.
>> So .fppkg it is by default, and it remains so. Good old unix custom.
>>
> Avery wise choice.

I don't think the 'freedesktop' standard is much of a standard.

The ONLY programs that I know of that write to ~/.config are the
programs using the sysutils GetAppConfigDir.

None of the installed programs on my system use it. KDE writes to
.kde4/whatever and all the rest writes to ~/.someprogramconfigfile.

Like I said, it was a mistake to have followed the 'standard'.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: fpmake: output directories

Graeme Geldenhuys-2
2009/6/3 Michael Van Canneyt <[hidden email]>:
>
> I don't think the 'freedesktop' standard is much of a standard.
> Like I said, it was a mistake to have followed the 'standard'.

Well if everybody thinks like that, then NOTHING will become a
standard. The "dot" files idea is a mess, the FHS is a mess.

I greatly appreciate the efforts freedesktop.org and LSB are trying to
do. The application development under Linux, *BSD, etc is a huge mess
compared to OS X and Windows.


> The ONLY programs that I know of that write to ~/.config are the
> programs using the sysutils GetAppConfigDir.

Well, I have a new Ubuntu 8.04 install which is about 1.5 months old.
I already have the following applications that use the ~/.config
directory.

  BeyondCompare
  Tracker
  Compiz
  Qt (not KDE based)
  Totem
  GTK-2.0
  DoubleCmd
  Menus (various apps registering there desktop and menu icons here)
  ...

So that's not bad for a developer only PC.  And I left out all the
Free Pascal based applications like, FPCUnit, Lazarus, Lazarus Data
Desktop, TutorAdmin, fpGUI UI Designer, etc..

So my opinion, is that it is great that there is an effort no get some
desktop application standard going. That way developers can query an
environment variable to detect the users preferred directory
locations, preferd editor, web browser, image viewer, video player
etc... Otherwise how else is a Linux application developer going to
query such things.

I'm all for some desktop standards under Linux! :-)

BTW:
Michael, did you know that you *can* set your $XDG_CONFIG_HOME
environment variable so that it uses something other that ~/.config/
directory.  The ~/.config/ is simply the default location if the
$XDG_CONFIG_HOME environment variable is not set.


Regards,
  - Graeme -


_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: fpmake: output directories

Michael Van Canneyt


On Wed, 3 Jun 2009, Graeme Geldenhuys wrote:

> 2009/6/3 Michael Van Canneyt <[hidden email]>:
>>
>> I don't think the 'freedesktop' standard is much of a standard.
>> Like I said, it was a mistake to have followed the 'standard'.
>
> Well if everybody thinks like that, then NOTHING will become a
> standard. The "dot" files idea is a mess, the FHS is a mess.

FHS, I don't know; But .dot files are IMHO easy to grasp.

I really don't see what the problem is with the .dot files, and why this
custom had to be changed.


> I greatly appreciate the efforts freedesktop.org and LSB are trying to
> do. The application development under Linux, *BSD, etc is a huge mess
> compared to OS X and Windows.

Why ? Windows is even more of a mess as far as I'm concerned,
and I develop on it since years. With each version of windows,
I'd have to relocate all my application files. Debugging problems
is next to impossible, because Windows is a black box. No thanks.


>> The ONLY programs that I know of that write to ~/.config are the
>> programs using the sysutils GetAppConfigDir.
>
> Well, I have a new Ubuntu 8.04 install which is about 1.5 months old.
> I already have the following applications that use the ~/.config
> directory.
>
>  BeyondCompare
>  Tracker
>  Compiz
>  Qt (not KDE based)
>  Totem
>  GTK-2.0
>  DoubleCmd
>  Menus (various apps registering there desktop and menu icons here)
>  ...

Probably the fact that I use KDE - which has it's own tree - explains
that my directory is empty.

> So that's not bad for a developer only PC.  And I left out all the
> Free Pascal based applications like, FPCUnit, Lazarus, Lazarus Data
> Desktop, TutorAdmin, fpGUI UI Designer, etc..
>
> So my opinion, is that it is great that there is an effort no get some
> desktop application standard going. That way developers can query an
> environment variable to detect the users preferred directory
> locations, preferd editor, web browser, image viewer, video player
> etc... Otherwise how else is a Linux application developer going to
> query such things.
>
> I'm all for some desktop standards under Linux! :-)

So am I, but I don't have the impression that the freedesktop one
is much followed.

> BTW:
> Michael, did you know that you *can* set your $XDG_CONFIG_HOME
> environment variable so that it uses something other that ~/.config/
> directory.  The ~/.config/ is simply the default location if the
> $XDG_CONFIG_HOME environment variable is not set.

I know this, but in practice, what can I set it to ? $HOME is not an
option, because then my home directory is cluttered with visible
files and directories.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: fpmake: output directories

Graeme Geldenhuys-2
2009/6/3 Michael Van Canneyt <[hidden email]>:
>
> Why ? Windows is even more of a mess as far as I'm concerned,

The only nice thing is you can query the system for some basic
applications: eg: I need to open a text file, I know notepad.exe will
exist. etc...  At least now with the xdg-open command and it's various
settings this can now be done in Linux as well.


> Probably the fact that I use KDE - which has it's own tree - explains
> that my directory is empty.

I must say, that is one think about KDE (compared to Gnome). KDE is a
lot more consistent in it's config locations across various KDE based
applications. And KDE is also a lot more consistent in it's UI across
various KDE based applications.

Issues I frequently see in Gnome:
  * I enable menu tear-off feature.  Very few apps adhere to that setting.
  * File Open & Save dialogs. I have seen so many apps that have different
     versions of those dialogs.
  * UI layout varies from application to application.
  ....

But for some reason, I just find it hard to switch to KDE. I used to
be a big KDE fan in the Suse 7 & 8 days, but in recent years I started
using Ubuntu and just got used to Gnome.

What widgetset do you have Lazarus IDE compiled with? Qt, GTK2, GTK1?
Recently I made the switch from GTK1 to GTK2.


> I know this, but in practice, what can I set it to ? $HOME is not an option,
> because then my home directory is cluttered with visible
> files and directories.

True... You can always set it to $HOME and implement
OnGetApplicationName which prefixes a "dot" infront of you application
name when the system runs under a unix environment.  But then, maybe
that's to much effort. :-)

What's your issue with the ~/.config/ directory?  How often you to
browse those folders anyway?  I know I hardly do.

My issue with the "dot" directories in the $HOME directory. I have no
idea how to list only the "dot" directories. What I use is this...

  $> ls -lsa

But that lists "dot" directories and everything else.  Maybe I just
don't know bash well enough yet.  :-(


Regards,
  - Graeme -


_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: fpmake: output directories

Michael Van Canneyt


On Wed, 3 Jun 2009, Graeme Geldenhuys wrote:

> 2009/6/3 Michael Van Canneyt <[hidden email]>:
>>

> lot more consistent in it's config locations across various KDE based
> applications. And KDE is also a lot more consistent in it's UI across
> various KDE based applications.
>
> Issues I frequently see in Gnome:
>  * I enable menu tear-off feature.  Very few apps adhere to that setting.
>  * File Open & Save dialogs. I have seen so many apps that have different
>     versions of those dialogs.
>  * UI layout varies from application to application.
>  ....
>
> But for some reason, I just find it hard to switch to KDE. I used to
> be a big KDE fan in the Suse 7 & 8 days, but in recent years I started
> using Ubuntu and just got used to Gnome.

Use Kubuntu ? I do, now.

>
> What widgetset do you have Lazarus IDE compiled with? Qt, GTK2, GTK1?
> Recently I made the switch from GTK1 to GTK2.

So did I :-)

>
>
>> I know this, but in practice, what can I set it to ? $HOME is not an option,
>> because then my home directory is cluttered with visible
>> files and directories.
>
> True... You can always set it to $HOME and implement
> OnGetApplicationName which prefixes a "dot" infront of you application
> name when the system runs under a unix environment.  But then, maybe
> that's to much effort. :-)
>
> What's your issue with the ~/.config/ directory?  How often you to
> browse those folders anyway?  I know I hardly do.

Very often. Almost daily.

>
> My issue with the "dot" directories in the $HOME directory. I have no
> idea how to list only the "dot" directories. What I use is this...
>
>  $> ls -lsa

ls -lad .*

does what you ask...

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: fpmake: output directories

Graeme Geldenhuys-2
2009/6/3 Michael Van Canneyt <[hidden email]>:
>
> Use Kubuntu ? I do, now.

I did for Kubuntu 9.04, and then had to revert back to 8.04 LTS
because 9.04 had to many graphics issues (X11 drawing bugs which I
reported and affected fpGUI, MSEgui and WINE). But damn, Kubuntu 9.04
did look beautiful.

>
> ls -lad .*
>
> does what you ask...

I should have used Google a long time ago. :-) Here are some
variations (slight improvements for me) on that command.


alias lh='ls -Adx --group-directories-first .*'
alias lhd='ls -dx .*/'


lh - lists directories and files. But directories first and orders
them by line (across the screen) and not in columns (downwards).

lhd - only lists hidden directories, no files.




Regards,
  - Graeme -


_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: fpmake: output directories

Mattias Gaertner
In reply to this post by Michael Van Canneyt
On Tue, 2 Jun 2009 16:03:08 +0200 (CEST)
Michael Van Canneyt <[hidden email]> wrote:

>[...]
> > Thanks.
> > Maybe this can be used for debug/release.
> > I don't see how this can be used for the widgetsets.
>
> Why not ? you can use
>   subtarget=gtk2-debug

How can I pass sub targets to fppkg?


> > My dream is this:
> > User opens a project and/or package and the IDE uses fppkg to
> > download and install automatically the missing packages.
> > Some packages like the LCL are already installed via lazarus. So
> > somehow fppkg needs to know, that some packages don't need be
> > downloaded from the repositories. Maybe lazarus can register a
> > local repository?
>
> fppkg will see what is installed locally, and will not download what
> is already there (unless the versions don't match).
>
> The point is that the LCL must be installed in the package system, so
> fppkg knows about it. That means an additional copy operation.
>
> If you don't want that, then we must see about 'registering' local
> build trees in fppkg; By this I mean that fppkg assumes that all is
> installed under
>
> ~user/.fppkg/build/
>
> (or something like it)
>
> if you don't want this, you should be able to tell it that it should
> also look in e.g.
>
> /path/to/lazarusdir/components/
>
> To find additional packages there.

If root installs some packages for all users and I want to add some
extra packages. Can fppkg handle this?

Mattias
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: fpmake: output directories

Peter Vreman
>>> Maybe this can be used for debug/release.
>>> I don't see how this can be used for the widgetsets.
>> Why not ? you can use
>>   subtarget=gtk2-debug
>
> How can I pass sub targets to fppkg?

fppkg -c<configname>

You can already use this now for cross-compiling. Under Linux you can
test it with:
- Copy ~/.fppkg/config/default to ~/.fppkg/config/win32
- Change target in ~/.fppkg/config/win32 to win32
- Start "fppkg -cwin32 install fpc-all"


>> The point is that the LCL must be installed in the package system, so
>> fppkg knows about it. That means an additional copy operation.
>>
>> If you don't want that, then we must see about 'registering' local
>> build trees in fppkg; By this I mean that fppkg assumes that all is
>> installed under
>>
>> ~user/.fppkg/build/
>>
>> (or something like it)
>>
>> if you don't want this, you should be able to tell it that it should
>> also look in e.g.
>>
>> /path/to/lazarusdir/components/
>>
>> To find additional packages there.
>
> If root installs some packages for all users and I want to add some
> extra packages. Can fppkg handle this?

Yes. It supports a Global and a Local directory. The local directory has
a higher preference.

Peter
_______________________________________________
fpc-pascal maillist  -  [hidden email]
http://lists.freepascal.org/mailman/listinfo/fpc-pascal