guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: New build-system quest (premake4 t-engine)


From: Oleg Pykhalov
Subject: Re: New build-system quest (premake4 t-engine)
Date: Wed, 26 Jul 2017 09:25:11 +0300
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux)

Ricardo Wurmus <address@hidden> writes:

>>> Have you tried using the “gnu-build-system” and replacing the configure
>>> phase with your invocation of premake4?
>>
>> I did it like you wrote.
>>
>> But the problem was tome4 (t-engine) wants config=release.
>
> I’m not sure what this means, but if this is an argument to “make” you
> can pass it to the build phase with the #:make-flags field of the
> build system arguments.
>
> If it’s about the invocation of premake you would just do that in your
> replaced configure phase:
>
>     (zero? (system* "premake4" "config=release" …))

Thanks!  Yes, it needs to be set as argument to “make”.  This is exactly
what I did.

>> Firstly I thought that it will be good to have a different build system
>> for premake in future, so we don't need always to overwrite configure
>> phase.
>>
>> May be I'm wrong and it's OK to do all the time, I'm not sure.
>
> It might be useful, but I don’t know how often that would be needed.
> Our build systems so far each cover a very large number of packages.  If
> it turns out that many more packages would need to do the same steps I
> think it would be fine to add a new build system.

Yes, I think the same.  There are also different versions of premake
which I believe works different.  Might be tricky to do this.

>>> One difference between “guix build” and “guix environment” is that the
>>> latter builds a profile first, so environment variables for libraries or
>>> headers really only have to be set to a single directory
>>> (e.g. $GUIX_ENVIRONMENT/lib or $GUIX_ENVIRONMENT/include).
>>>
>>> “guix build”, on the other hand, builds up long chains of directories as
>>> the values for these environment variables.
>>
>> Hm, do they both produce kinda the same environment in native?
>
> It’s similar, but not the same.  Some applications cannot really deal
> with a search path that involves multiple directories.  PyQt, for
> example, only looks in a single hard-coded directory for extensions, so
> it would find them inside of “guix environment” but not in a build
> environment.

Good to know, thanks!


I'm a little bit confusing about kinda patching in “snippet” vs “phase”.
After I made both in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=27691
I thought maybe I could move “snippet” to “phase”.  What is the
difference?  

Right now I think that “snippet” is for patching and “phase”
modification is for “make” modification.  Could be both I guess, but
what about best practice?

(snippet
 '(for-each (lambda (file)
              (substitute* file
                (("#elif defined(__FreeBSD__)" line)
                 (string-append
                  line " || defined(__GNUC__)"))))
            '("src/music.h" "src/tSDL.h")))



reply via email to

[Prev in Thread] Current Thread [Next in Thread]