2008-04-11 14:07:49     Source in one place, configuration/output/build in another

Document created by Aaronwu Employee on Aug 6, 2013
Version 1Show Document
  • View in full screen mode

2008-04-11 14:07:49     Source in one place, configuration/output/build in another

Henrik Holm (UNITED STATES)

Message: 54109    I am trying to put configuration files and build output in a separate directory from the source tree -- the reason is that I want to do some source control on the configuration files and at the same time not have to put the full source tree under source control.   I keep the source tree read-only in order to make sure nothing gets modified that shouldn't.

 

What I try is

 

% cd ~/uClinux-source/uClinux-dist-2008R1-RC8/

% make O=~/uClinux-build menuconfig.

 

Unfortunately, this does not work, the config fails right away with the messages:

 

config/mkconfig > config.in

/bin/sh: config.in: Permission denied

make: *** [config.in] Error 1

 

This is of course because make tries to place a file within the source tree -- while I made it un-writable.

 

I believe the idea of the O environment variable is to ensure that output from configuration and build go in the "O" directory, but I guess I am using it wrong.  Does anyone else have experience in this?

 

Thanks,

Henrik Holm

QuoteReplyEditDelete

 

 

2008-04-11 14:10:51     Re: Source in one place, configuration/output/build in another

Henrik Holm (UNITED STATES)

Message: 54110    Hm, How do I get the newlines I put in when I type the message to appear in the posted message text? As it stands I see my post above is not easy to read :-( Thanks, Henrik

QuoteReplyEditDelete

 

 

2008-04-11 14:37:32     Re: Source in one place, configuration/output/build in another

Mike Frysinger (UNITED STATES)

Message: 54112    the fancy editor is broken for some browsers.  only option is to use a different browser.

QuoteReplyEditDelete

 

 

2008-04-11 14:39:56     Re: Source in one place, configuration/output/build in another

Mike Frysinger (UNITED STATES)

Message: 54113    uClinux-dist does not support separating of build and source and probably wont for a long time (if ever) ... it'd require all the source packages to also support the notion, and many dont

QuoteReplyEditDelete

 

 

2008-04-11 15:33:01     Re: Source in one place, configuration/output/build in another

Graham Davies (UNITED STATES)

Message: 54116    In case this helps, I started out trying to do something similar to what you're trying to do.

 

Regarding "source control on the configuration files", refer to the thread "How to preserve configuration information in CVS".  In message 35848 I post the original question and in message 35902 I summarize the solution I found.

 

I imagine you're trying to "not have to put the full source tree under source control" because of how long source control operations will take to sift through a gigabyte of stuff to find the file you've altered.  I tried to solve this problem by putting the distribution into a different source control module from my application and drivers.  I then checkout my stuff, separately export the distribution and copy the export over my stuff, being careful not to overwrite anything.  This sort-of works, but I wish there was a better way.  There probably is in more modern source management software, but because of company policy my only option is CVS.  Maybe I should have spent a day or two typing up .cvsignore files.

 

Anyway, if this helps, good, if it doesn't, sorry for the noise.  I am not asking a question.  I don't have a problem I'm asking anyone to solve.  I'm just trying to pitch in a bit of help.

 

Graham.

QuoteReplyEditDelete

 

 

2008-04-11 18:07:01     Re: Source in one place, configuration/output/build in another

Henrik Holm (UNITED STATES)

Message: 54127    Thanks!

 

At least I won't have to wrestle with trying to get it to work, when I know that it's not supposed to :-)

 

Henrik (now trying with Firefox instead of Safari.)

QuoteReplyEditDelete

 

 

2008-04-11 18:22:45     Re: Source in one place, configuration/output/build in another

Henrik Holm (UNITED STATES)

Message: 54128    Thanks Graham,

 

I think we have a very similar problem, although I would like to avoid putting uClinux under source control altogether -- I don't think IT would be happy with be dumping 2 GB into the repository.   One alternative might be to strip out some large subtrees that I know we won't be needing, but sifting through what is and isn't needed is a rather heavy task.

 

Yours sounds like a good idea.  I was thinking about something similar, although my initial intention was to do it the opposite way -- i.e., copy the changes into/on top of the source tree.  The problem with that is of course that I will modify the pristine tree -- exactly what i wanted to avoid.

 

Thanks,

Henrik

QuoteReplyEditDelete

 

 

2008-04-14 13:11:20     Re: Source in one place, configuration/output/build in another

Graham Davies (UNITED STATES)

Message: 54203    I did not consider *not* putting uClinux under source control.  Disk space is pretty cheap these days and since I really do need a record of the code I started with, it might as well be in CVS as in a directory on my workstation.

 

Stripping out stuff you know you'll never need will cut down what you have to put under source control, but unless you automate this with a script you will regret it when you need to import a new uClinux distribution.  Cutting out the first few hundred magabytes is pretty easy, but to get something like an order of magnitude reduction in size could take days.  I have tried this and I agree that it is "a rather heavy task".

 

The reason I chose to copy the stuff I don't change into my work area rather than the other way around (copy my changes into the static source tree, as you suggest) is that as a result of some very unpleasant experiences a decade or so ago, I am very wary of moving or copying CVS sandboxes.  I am probably paranoid and it would probably work.  But, my impression of CVS is that it was designed to do the unexpected and it lives up to this goal.  Henrik, you don't say what source control software you are using, but I hope you're not using CVS so don't let my paranoia influence you unduly.

 

Graham.

QuoteReplyEditDelete

 

 

2008-04-14 14:16:07     Re: Source in one place, configuration/output/build in another

Mike Frysinger (UNITED STATES)

Message: 54205    ive found git to be useful in the case where you're working against a large tree with your own customizations ...

 

create a branch against the upstream tree, and then when you update the mainstream tree, just rebase your branch and git will handle all of the reapplying of your changes ...

QuoteReplyEditDelete

 

 

2008-04-15 07:22:15     Re: Source in one place, configuration/output/build in another

Henrik Holm (UNITED STATES)

Message: 54268    Mike, Graham,

 

Thanks for your input.  I should have said right away that we are using Subversion for source control.  I am afraid Git is not an option for us, although it seems quite intriguing.

 

I think our solution will be to set up a separate repository for the Linux source code, with a branch for all our changes.  That way we keep the source tree pristine, and only the people who really need the Linux source get it.

 

Thanks,

Henrik

QuoteReplyEditDelete

 

 

2008-04-15 10:36:35     Re: Source in one place, configuration/output/build in another

Graham Davies (UNITED STATES)

Message: 54280    Henrik,

 

Subversion is probably a better choice than CVS.  But, it was written by the same people that wrote CVS and Linus is pretty dismissive of it so it may suffer from some of the same flaws.  My point is, putting the uClinux distribution on the head branch in CVS turned out to be a big mistake.  CVS wants "vendor" code distributions to be on branches.  Only then can you use the 'import' command to bring in subsequent distributions and have CVS figure out new and deleted files properly.  You're supposed to merge the vendor branch to the head branch and make your changes from there, using development branches as necessary to separate threads of work.  So, you might want to make sure that something like this doesn't also apply to Subversion before you proceed.  Or, maybe someone else will just know one way or the other and post a comment.

 

Graham.

Attachments

    Outcomes