Patch: Repair the support for directory variables.

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Patch: Repair the support for directory variables.

Björn Persson-3
Hello!

To upgrade the GTKada package in Fedora I had to fix the support for
directory variables again. This version of the patch applies to the
trunk.

Björn Persson

_______________________________________________
gtkada mailing list
[hidden email]
http://lists.adacore.com/mailman/listinfo/gtkada

0001-Repaired-the-support-for-directory-variables.patch (4K) Download Attachment
attachment1 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Patch: Repair the support for directory variables.

Nicolas Setton
Hello Björn,

> To upgrade the GTKada package in Fedora I had to fix the support for
> directory variables again. This version of the patch applies to the
> trunk.

Thank you for the patch! If you don't mind, could you please submit this
as a github pull request for

   https://github.com/AdaCore/gtkada

(We would like to make github pull requests the official way of
contributing patches)

And same question for your testgtk patch.

Nicolas
_______________________________________________
gtkada mailing list
[hidden email]
http://lists.adacore.com/mailman/listinfo/gtkada
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Patch: Repair the support for directory variables.

Emmanuel Briot
In reply to this post by Björn Persson-3
> To upgrade the GTKada package in Fedora I had to fix the support for
> directory variables again. This version of the patch applies to the
> trunk.


Thanks for the patch.
In addition to Nicolas' suggestion of using github, a few quick comments on your
patch:

You mention that gprinstall's Artifacts attribute requires a hard-coded path. Would it
work to use something like the following in testgtk.gpr instead :

    Exampledir := external("EXAMPLEDIR", "share/examples/gtkada/testgtk");
    for artifacts (Exampledir) use (....)

and then call gprinstall from the makefile with something like:

   gprinstall -XDESTDIR="${DESTDIR}" -XEXAMPLEDIR="${exampledir}"

I did not try this, so it might indeed not work as expected, but it would be cleaner I think.

regards
Emmanuel
_______________________________________________
gtkada mailing list
[hidden email]
http://lists.adacore.com/mailman/listinfo/gtkada
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Patch: Repair the support for directory variables.

Björn Persson-3
Emmanuel Briot <[hidden email]> wrote:

> You mention that gprinstall's Artifacts attribute requires a
> hard-coded path. Would it work to use something like the following in
> testgtk.gpr instead :
>
>     Exampledir := external("EXAMPLEDIR",
> "share/examples/gtkada/testgtk"); for artifacts (Exampledir) use
> (....)
>
> and then call gprinstall from the makefile with something like:
>
>    gprinstall -XDESTDIR="${DESTDIR}" -XEXAMPLEDIR="${exampledir}"
>
> I did not try this, so it might indeed not work as expected, but it
> would be cleaner I think.
Of course i tried the obvious. It made the project file syntactically
invalid. GPRbuild requires a string literal, and so does the BNF in the
GPRbuild User's Guide. Well it was GPRbuild 2015 that I tried it with,
but the GPRbuild and GPR Companion Tools User’s Guide 2016 still
requires a literal.

As long as that's the case I don't find Artifacts to be of much use for
a portable project. A cp command in the makefile works better.

Björn Persson

_______________________________________________
gtkada mailing list
[hidden email]
http://lists.adacore.com/mailman/listinfo/gtkada

attachment0 (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Patch: Repair the support for directory variables.

Emmanuel Briot
>>    Exampledir := external("EXAMPLEDIR",
>> "share/examples/gtkada/testgtk"); for artifacts (Exampledir) use
>> (....)
>>
>
> Of course i tried the obvious. It made the project file syntactically
> invalid. GPRbuild requires a string literal, and so does the BNF in the
> GPRbuild User's Guide. Well it was GPRbuild 2015 that I tried it with,
> but the GPRbuild and GPR Companion Tools User’s Guide 2016 still
> requires a literal.

Which part requires a literal string in my example ? (I agree that there are
a number of cases in which gpr files must have literal strings, and sometimes
even for good reasons :-)
But in my example, I am using a literal string for the default value of "external",

Would you share (if you still have it) the experiment you performed ?

> As long as that's the case I don't find Artifacts to be of much use for
> a portable project. A cp command in the makefile works better.

True if you are only aiming at linux.
Not so if you want to support multiple systems.

Thanks !
Emmanuel
_______________________________________________
gtkada mailing list
[hidden email]
http://lists.adacore.com/mailman/listinfo/gtkada
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Patch: Repair the support for directory variables.

Björn Persson-3
Emmanuel Briot <[hidden email]> wrote:

> >>    Exampledir := external("EXAMPLEDIR",
> >> "share/examples/gtkada/testgtk"); for artifacts (Exampledir) use
> >> (....)
> >>
> >
> > Of course i tried the obvious. It made the project file syntactically
> > invalid. GPRbuild requires a string literal, and so does the BNF in the
> > GPRbuild User's Guide. Well it was GPRbuild 2015 that I tried it with,
> > but the GPRbuild and GPR Companion Tools User’s Guide 2016 still
> > requires a literal.
>
> Which part requires a literal string in my example ? (I agree that there are
> a number of cases in which gpr files must have literal strings, and sometimes
> even for good reasons :-)
> But in my example, I am using a literal string for the default value of "external",
>
> Would you share (if you still have it) the experiment you performed ?
I have now found the time to write a reproducer, and also checked that
it fails with GPRbuild 2016 too. In the attachment, the difference
between literal.gpr and variable.gpr is the change that you suggested.
Please run it and see what happens.

Björn Persson

_______________________________________________
gtkada mailing list
[hidden email]
http://lists.adacore.com/mailman/listinfo/gtkada

gpr_artifacts_test.tar.gz (814 bytes) Download Attachment
attachment1 (836 bytes) Download Attachment
Loading...