[Lazarus] How would you organize build directories for different versions?

[Frank Church]

On 3 October 2010 11:41, Frank Church <vfclists at gmail.com> wrote:

>
>
> On 29 September 2010 08:38, Mattias Gaertner <nc-gaertnma at netcologne.de>wrote:
>
>> On Wed, 29 Sep 2010 06:59:02 +0100
>> Frank Church <vfclists at gmail.com> wrote:
>>
>> > If you are using different Lazarus versions but with same components and
>> > packages, how would you organize separate build directories for the
>> > different versions, but same source location.
>> >
>> > eg. say I am using fpc 2.2.4/ lazarus 0.9.28, fpc 2.4.0 / lazarus 0.9.29
>> and
>> > fpc 2.5.1/ lazarus 0.9.29
>> >
>> > All though the package source files would be in one place (with
>> necessary
>> > ifdefs for compiler and lazarus versions) I would like the units to go
>> into
>> > say lazarus_0928_224/components/package_name_dir,
>> lazarus0928240/components
>> > package_name_dir, lazarus0929251/components/package_name_dir.
>> >
>> > Would I have to configure that in the separate IDEs, or in the package
>> > source files themselves?
>>
>> There are many ways.
>> For example use one lazarus config directory for each version
>> combination and make all package output directories read only. Then the
>> IDE will put the ppu files into the config directory.
>>
>>
>>
> Can this be achieved via macros?
>
>  For instance I have just posted a blog article on FPC/Lazarus compilaton
> at
> http://devblog.brahmancreations.com/content/build-scripts-for-installing-freepascal-and-lazarus-from-source,
> and what I want to do is to have the build_name variable as available to the
> IDE.
>
> e.g if a lazarus build is named lazarus_0920_27001, I would like to use a
> macro based on the package name as well as the lazarus build name, so the
> compiler knows that units for zeoslib for instance go to directory
> /components/lazarus_0920_27001/zeoslib.
>
> Even if the package sources must be modified that should be a minor
> problem.
>
> Surely something like that must be possible.
>
> I think it would also solve the problem of backporting packages made for
> fpc 2.5.1/lazarus 0.9.29 to the 0.9.28 and even the 0.9.26 series as it is
> extremely unlikely that they depend on language features only present in fpc
> 2.5.1.
>
> Delphi developers are still producing code compatible with Delphi 7. Delphi
> 7 still appears to be the reference platform for Delphi development.
>
>
>
>
>> Mattias
>>
>>
>> --
>> _______________________________________________
>> Lazarus mailing list
>> Lazarus at lists.lazarus.freepascal.org
>> http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
>>
>
>
> --
> Frank Church
>
> =======================
> http://devblog.brahmancreations.com
>

I am looking at
http://wiki.lazarus.freepascal.org/IDE_Macros_in_paths_and_filenames and I
am considering using a combinatin of PrimaryConfigPath and  package name to
set the output directory.


   - *Package macros* - these can be used in the fields of a package. For
   example in the search paths of a package. To use them elsewhere give a
   package name as parameter.
      - *PkgDir()* - macro function for the directory (location of the .lpk)
      of a package ID given as parameter
      - *PkgIncPath(id)* - macro function for the include path of a package
      ID given as parameter
      - *PkgOutDir(id)* - macro function for the output directory of a
      package (e.g. where the ppu files are created)
      - *PkgSrcPath(id)* - macro function for the source path (unit path +
      src path) of a package ID given as parameter
      - *PkgUnitPath(id)* - macro function for the unit path of a package ID
      given as parameter


However there doesn't seem to be a macro for the package name itself in the
package related macros. Can NameOnly(xxx) be applied to one of the above
macros to obtain the package name referring to "packagename.lpk"? As
packages have their own directories, I might settle for a macro to retrieve
the last element of the directory so that ..\components\componentdir
produces componentdir. I want to avoid having to edit the packages
themselves, or just edit them in one place.

I'd like to use a combination of ConfPath or PrimaryConfigPath or the
FallBackOutputRoot to handle the issue.

Something like
PrimaryConfigPath\NameOnly(packagepath)\lib/$(TargetCPU)-$(TargetOS) would
be ideal.

Do ConfPath and PrimaryConfigPath refer to the same thing?

-- 
Frank Church

=======================
http://devblog.brahmancreations.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20110714/abba31e6/attachment-0002.html>