Out-of-tree builds?

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

Out-of-tree builds?

David Chisnall-7
Hello the list,

I need to build GNUstep in a couple of different configurations, for testing.  For most projects, I would do this by using out-of-tree builds, but this doesn’t appear to work for GNUstep.  Is there a mechanism for doing this that I can’t find, or is it just a limitation of the build system?

David


_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: Out-of-tree builds?

Richard Frith-Macdonald-9


> On 20 Mar 2018, at 13:04, David Chisnall <[hidden email]> wrote:
>
> Hello the list,
>
> I need to build GNUstep in a couple of different configurations, for testing.  For most projects, I would do this by using out-of-tree builds, but this doesn’t appear to work for GNUstep.  Is there a mechanism for doing this that I can’t find, or is it just a limitation of the build system?

I'm fairly sure it's not supported;
I remember seeing an ancient patch to add this on savannah, but I hadn't noticed it when new.  It might be easy to apply, but I suspect it's too old to be helpful.
Even if I had seen it I'm not sure I'd have jumped in to apply it myself, since I've never been on a system with so little disk space that I needed/wanted to build that way.


_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: Out-of-tree builds?

David Chisnall-7
On 20 Mar 2018, at 15:03, Richard Frith-Macdonald <[hidden email]> wrote:

>
>
>
>> On 20 Mar 2018, at 13:04, David Chisnall <[hidden email]> wrote:
>>
>> Hello the list,
>>
>> I need to build GNUstep in a couple of different configurations, for testing.  For most projects, I would do this by using out-of-tree builds, but this doesn’t appear to work for GNUstep.  Is there a mechanism for doing this that I can’t find, or is it just a limitation of the build system?
>
> I'm fairly sure it's not supported;
> I remember seeing an ancient patch to add this on savannah, but I hadn't noticed it when new.  It might be easy to apply, but I suspect it's too old to be helpful.
> Even if I had seen it I'm not sure I'd have jumped in to apply it myself, since I've never been on a system with so little disk space that I needed/wanted to build that way.

It has nothing to do with disk space, it has to do with my sanity.  With libobjc2 (and LLVM, Clang, and most other projects I use), I have a single checkout of the code and build directories for release and debug versions (and some more exotic ones for cross-compilation or testing newer compilers).  If I find a bug in my release build, I can build exactly the same sources in a debug config by changing to the correct directory and typing ‘ninja’.  If I think I have fixed the bug, I can change to the release directory, rebuild there, and see if it’s gone away in the original place.

Because they are in separate directories, there is no chance of pollution between them and I get incremental rebuilds of all configurations when I change any source.  This is invaluable with cross-compiling, if I want to test a change on x86, ARM and MIPS, or even just 32- and 64-bit x86 versions.

And, as an aside, I can often stick the build directories in faster but less reliable storage (I don’t care if I lose my build directories if the power goes out, I do care if I lose my source directories.  I want my source directories to be spread across disks in a RAID configuration with redundancy, but I’m happy for my build directories to have no redundancy and fewer syncs, so infrequently-written files stay in RAM).  

Oh, and for the CMake ones I also typically have a build directory that uses XCode so that I can use the static analyser and refactoring tools from there, rather than via the command line.

David


_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: Out-of-tree builds?

Ivan Vučica-2

On Tue 20 Mar 2018 at 15:18 David Chisnall <[hidden email]> wrote:
On 20 Mar 2018, at 15:03, Richard Frith-Macdonald <[hidden email]> wrote:
>
>
>
>> On 20 Mar 2018, at 13:04, David Chisnall <[hidden email]> wrote:
>>
>> Hello the list,
>>
>> I need to build GNUstep in a couple of different configurations, for testing.  For most projects, I would do this by using out-of-tree builds, but this doesn’t appear to work for GNUstep.  Is there a mechanism for doing this that I can’t find, or is it just a limitation of the build system?
>
> I'm fairly sure it's not supported;
> I remember seeing an ancient patch to add this on savannah, but I hadn't noticed it when new.  It might be easy to apply, but I suspect it's too old to be helpful.
> Even if I had seen it I'm not sure I'd have jumped in to apply it myself, since I've never been on a system with so little disk space that I needed/wanted to build that way.

It has nothing to do with disk space, it has to do with my sanity.  With libobjc2 (and LLVM, Clang, and most other projects I use), I have a single checkout of the code and build directories for release and debug versions (and some more exotic ones for cross-compilation or testing newer compilers).  If I find a bug in my release build, I can build exactly the same sources in a debug config by changing to the correct directory and typing ‘ninja’.  If I think I have fixed the bug, I can change to the release directory, rebuild there, and see if it’s gone away in the original place.

Because they are in separate directories, there is no chance of pollution between them and I get incremental rebuilds of all configurations when I change any source.  This is invaluable with cross-compiling, if I want to test a change on x86, ARM and MIPS, or even just 32- and 64-bit x86 versions.

And, as an aside, I can often stick the build directories in faster but less reliable storage (I don’t care if I lose my build directories if the power goes out, I do care if I lose my source directories.  I want my source directories to be spread across disks in a RAID configuration with redundancy, but I’m happy for my build directories to have no redundancy and fewer syncs, so infrequently-written files stay in RAM).

Oh, and for the CMake ones I also typically have a build directory that uses XCode so that I can use the static analyser and refactoring tools from there, rather than via the command line.

Overlayfs or one of its equivalents?

--
Sent from Gmail Mobile

_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: Out-of-tree builds?

Riccardo Mottola-5
In reply to this post by David Chisnall-7
Hi,

David Chisnall wrote:
> I need to build GNUstep in a couple of different configurations, for testing.  For most projects, I would do this by using out-of-tree builds, but this doesn’t appear to work for GNUstep.  Is there a mechanism for doing this that I can’t find, or is it just a limitation of the build system?

as far as I know, no, a gnustep-make limitation. It would be something
very useful to have.

E.g. on system with limited (or "slow") diskspace, but also on systems
where GIT and SVN (with TLS upgrade  for github lately) are not working.
I could have a single source checked out on a "server" machine and then
NFS mound the sources on different architectures and be sure to build.

Think more: if I develop a patch and want to test it, I need to create
the patch, copy it ofer a couple of machines, build and then if all is
OK, check it in.
The other way, I could develop the patch, test it on a standard machine,
then all other machines would see the same "patched" sources, if
everything builds, I can easily commit without having to patch N
different source trees.

Even more, I could have a GCC and a Clang build in the same machine
coming from the same source tree.

Possibilities are endless!



Riccardo

_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: Out-of-tree builds?

Yavor Doganov-3
In reply to this post by David Chisnall-7
В Tue, 20 Mar 2018 13:04:15 +0000, David Chisnall написа:

> For most projects, I would do this by using out-of-tree builds, but
> this doesn’t appear to work for GNUstep.  Is there a mechanism for
> doing this that I can’t find, or is it just a limitation of the
> build system?

It is easy to add support for it for any GNUstep project that is using
GNU Autoconf:

- Add GNUmakefile to AC_CONFIG_FILES
- Incorporate all the auxiliary makefiles (.preamble/.postamble/etc)
  into the main makefile; alternatively add them to AC_CONFIG_FILES as
  well
- Add the following line to the makefile

  srcdir := @srcdir@

- Adjust all variables to honor srcdir, for example instead of

  foo_OBJC_FILES = foo.m \
  bar.m \
  maude.m

  write

  foo_OBJC_FILES = $(addprefix $(srcdir)/, \
  bar.m \
  maude.m)

Of course all of this should be done automatically and behind the
scenes by GNUstep Make.  I fully agree that out-of-tree builds have
many valuable applications and most people quite reasonably expect
this feature.  It should work out of the box for any sane build
system.

A different approach would be to play with the vpath GNU make
directive but makefiles must be in builddir in any case.


_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Reply | Threaded
Open this post in threaded view
|

Re: Out-of-tree builds?

David Chisnall-7
On 20 Mar 2018, at 20:45, Yavor Doganov <[hidden email]> wrote:
>
> A different approach would be to play with the vpath GNU make
> directive but makefiles must be in builddir in any case.

I tried that, but unfortunately the GNUstep build still does recursive make (which is bad for a bunch of other reasons) and so you end up needing to do a fairly deep copy of the make files from src to obj, which then makes it possible for these to get out of sync and can cause other issues.

David


_______________________________________________
Gnustep-dev mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/gnustep-dev