search

steve-cs / gnat-builder

Makefile for downloading and building gnat from github source
2 stars 2 forks source link

Patch management discussion. #22

Closed Blady-Com closed 4 years ago

Blady-Com commented 4 years ago

Hello,

I have some patches on GTKAda and GNATColl to submit. I may understand that managing many patches according to dedicated targets is not an easy way in a makefile. I propose an other way: the changes are done in forked repositories of AdaCore ones and you can tell the makefile which repository you want to get, for instance: in makefile:

repo ?= adacore
repo-version ?= master
...
    git clone --depth=1 \
    https://github.com/$(repo)/gtkada -b $(repo-version) $@

on command line: make repo=my_project repo-version=21 gtkada

What do you think? Thanks, Pascal.

steve-cs commented 4 years ago

I prefer using adacore-repos rather than repo. It is actually the collection of more than one repository.

I think repo-version duplicates the adacore-version variable for your examples. Please note that I cannot replace all the branch/version usage with a single $(repo-version) as I need separate variables for libadalang and spark2014 in order to build development builds from a single call to gnat-builder.

Please look at commit https://github.com/steve-cs/gnat-builder/commit/74fb42586859146b029e43930ead3a9d72e03f65 to see my alternate implementation which might work for you. Example follows.

steve@ubuntu:~/gnat-builder$ make adacore-repos=Blady-Com adacore-version=proposal01_testgtk gtkada-src
git clone --depth=1 \
https://github.com/Blady-Com/gtkada -b proposal01_testgtk gtkada-src
Cloning into \'gtkada-src\'...
remote: Enumerating objects: 1119, done.
remote: Counting objects: 100% (1119/1119), done.
remote: Compressing objects: 100% (687/687), done.
remote: Total 1119 (delta 531), reused 585 (delta 418), pack-reused 0
Receiving objects: 100% (1119/1119), 5.58 MiB | 2.24 MiB/s, done.
Resolving deltas: 100% (531/531), done.

Thoughts?

Blady-Com commented 4 years ago

Thanks, it does the job. In fact, I'm using only separate calls of make, it is thus ok for me. I just need to adapt the various variables. An other question: As .git is now kept in src folders and thus could track file changes, is the copy into build folders still needed? Best Pascal.

steve-cs commented 4 years ago

[...] is the copy into build folders still needed?

Technically not, but it has simplified a few workflows for me. Much of it boils down to I trust myself with the file system more than I do git and it was a simple effective hack. Specifically it provided a simple reliable clean staging area for creating and testing patches. Separating the setup/config from the actual build/compile was occasionally useful and the existence of the -build directory was a simple indicator to make that it had been done. Historically there were things that weren't maintained in github. The one remaining one is the GCC compiler (actual releases as opposed to release branches). There might still be some minor interactions with gcc source and ./contrib/download_prerequisites which modifies the source tree, as well as spark2014 source which puts provers in nested git submodules. I'm confident that any issue could be easily worked around.

Summary: I've got enough caching and delayed writes on my development machine that making the additional copies hasn't bothered me.