This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Common GNU makefile directory path
After reading Recursive Make Considered Harmful I decided to use "include makefile" to my next project. I got a main Makefile that include two sub-makefiles that are in diffrent dirs. the problem is that the paths that inside the sub-makefile is relative to his dir so when I include it from the main Makefile he can't find the files. is there a way to solve this problem without changing the paths?
Although the article is right about recursive make and DAG tree, I read the article about half a year ago and tried to use the approach described in it and found the "classic" approach to recursive make much more convenient. Consider this:
big_project
|--Makefile
|
|--sub_project_1
| |--...
| |--Makefile
|
|--sub_project_2
|--...
|--Makefile
It's wonderful when you're running make from big_project project directory, but well, if you do things as it's recommended in the article, there would be no Makefiles in sub_project_x directories, thus you won't be able to treat each sub-project separately.
Related
This question already has answers here:
How can I build multiple binaries with Cargo?
(3 answers)
Package with both a library and a binary?
(4 answers)
Closed 3 years ago.
I'd like to create a rust package with two binary crates and a library which contains the shared code. I know how do do this for a simple program by putting the source files for the binaries in a src/bin/ subdirectory (e.g. src/bin/firstbin.rs and src/bin/secondbin.rs) and the library code either in src/ or in src/lib/.
However, if the binaries have a substantial amount of non-shared code which does not belong in the library, and I want to split their source into multiple files, I'm not sure of how to lay out the source files. I'm thinking something along the lines of having src/bin/firstbin/ for the files which belong only to the first binary, and src/bin/secondbin/ for the second binary. However, I'm not sure how to reference these files from firstbin.rs and secondbin.rs.
So is this the right approach and if so how do I reference the files? If not, what's the best layout?
You can put your fn main() into src/bin/firstbin/main.rs and add more files for submodules in the same directory. This is documented in this section of the Cargo manual (in the text, the gray box is wrong).
I have a directory with multiple source files of indeterminate name. The only thing I know is the file extension. I want to take each source file, and build a single target from each. The method I'm currently using is to determine the name of each source using a for loop:
targets = []
for file in listdir('.'):
if file.endswith('.xdm'):
targets += env.m4(source=file)
The advantage of doing it progrmatically like this is that the SConscript doesn't have to be maintained by the developers as they add new sources. The problem is that the targets are no longer cleaned because of something to do with dependencies that I don't entirely understand.
So my question is is there a more appropriate way to do this, using in-built SCons functionality, without relying on more traditional flow control, or should I just ensure that each of my sources is determined and list them individually in the SConscript?
Instead of fiddling with listdir I would simply use the Glob() method, as provided by SCons itself:
for file in Glob("*.xdm"):
env.m4(source=file)
This (like the example from your question) is a perfectly fine approach, since it uses the fact that SConscripts are actually Python scripts. The Glob() approach has the advantage of also finding *.xdm files that don't exist on the harddrive yet, but may get created as part of the build process later.
I wonder about the problems that you mentioned, regarding cleaning of the targets. The Q&A linked in your question above seems unrelated to me. If you experience actual "cleaning" problems with one of the approaches above, please post a separate question together with the full verbatim input and output. If it should turn out that this doesn't work out-of-the-box, I'd consider it to be a bug.
This question already has answers here:
How to obfuscate a shell script?
(4 answers)
Closed 6 years ago.
I wrote a nice program in linux and I don't want people to steal my work, is there a way for me to hide the contents of my sh file from other people seeing it when I publish it? And it still has to be functional when I publish it to the public. I won't be posting any of the code because of this.
You could consider adding an open source license to your program to protect it:
https://dzone.com/articles/selecting-an-open-source-license-for-your-project
One possibility is to compile the shell script to C and ship a binary executable. Compilers for the shell language exist, such as CCsh from Comeau Computing, which is a proprietary product, like yours.
What is the recommended way of having several cabal packages in one directory?
Why: I have an old project with many separable modules. Since originally they formed just one program it was, and still is, handy to have them in same directory for easy compiling.
Options
Just suffer and split everything, including VCS holding the stuff, into different directories?
Hack cabal until it is happy with multiple .cabal files in same directory?
Make another subdirectory for each module and put .cabal files there along with symlinks to original pieces of code?
Something smarter? What?
I'd have to recommend option 1 or 3 for cleanliness. I'm not sure how to get around this, if there is even a way to get around this.
I'd say a modified option of 1: subdirectories for everything, no symlinks, but keep everything under a single VCS.
This problem is on the issue list for Cabal 2.
I would recommend that this is exactly what workspaces in Leksah were designed to do. Just get your hands on Leksah and then the rest will sort itself out.
Mostly for my amusement, I created a makefile in my $HOME/bin directory called rebuild.mk, and made it executable, and the first lines of the file read:
#!/bin/make -f
#
# Comments on what the makefile is for
...
all: ${SCRIPTS} ${LINKS} ...
...
I can now type:
rebuild.mk
and this causes make to execute.
What are the reasons for not exploiting this on a permanent basis, other than this:
The makefile is tied to a single directory, so it really isn't appropriate in my main bin directory.
Has anyone ever seen the trick exploited before?
Collecting some comments, and providing a bit more background information.
Norman Ramsey reports that this technique is used in Debian; that is interesting to know. Thank you.
I agree that typing 'make' is more idiomatic.
However, the scenario (previously unstated) is that my $HOME/bin directory already has a cross-platform main makefile in it that is the primary maintenance tool for the 500+ commands in the directory.
However, on one particular machine (only), I wanted to add a makefile for building a special set of tools. So, those tools get a special makefile, which I called rebuild.mk for this question (it has another name on my machine).
I do get to save typing 'make -f rebuild.mk' by using 'rebuild.mk' instead.
Fixing the position of the make utility is problematic across platforms.
The #!/usr/bin/env make -f technique is likely to work, though I believe the official rules of engagement are that the line must be less than 32 characters and may only have one argument to the command.
#dF comments that the technique might prevent you passing arguments to make. That is not a problem on my Solaris machine, at any rate. The three different versions of 'make' I tested (Sun, GNU, mine) all got the extra command line arguments that I type, including options ('-u' on my home-brew version) and targets 'someprogram' and macros CC='cc' WFLAGS=-v (to use a different compiler and cancel the GCC warning flags which the Sun compiler does not understand).
I would not advocate this as a general technique.
As stated, it was mostly for my amusement. I may keep it for this particular job; it is most unlikely that I'd use it in distributed work. And if I did, I'd supply and apply a 'fixin' script to fix the pathname of the interpreter; indeed, I did that already on my machine. That script is a relic from the first edition of the Camel book ('Programming Perl' by Larry Wall).
One problem with this for generally distributable Makefiles is that the location of make is not always consistent across platforms. Also, some systems might require an alternate name like gmake.
Of course one can always run the appropriate command manually, but this sort of defeats the whole purpose of making the Makefile executable.
I've seen this trick used before in the debian/rules file that is part of every Debian package.
To address the problem of make not always being in the same place (on my system for example it's in /usr/bin), you could use
#!/usr/bin/env make -f
if you're on a UNIX-like system.
Another problem is that by using the Makefile this way you cannot override variables, by doing, for example make CFLAGS=....
"make" is shorter than "./Makefile", so I don't think you're buying anything.
The reason I would not do this is that typing "make" is more idiomatic to building Makefile based projects. Imagine if every project you built you had to search for the differently named makefile someone created instead of just typing "make && make install".
You could use a shell alias for this too.
We can look at this another way: is it a good idea to design a language whose interpreter looks for a fixed filename if you don't give it one? What if python looked for Pythonfile in the absence of a script name? ;)
You don't need such a mechanism in order to have a convention based around a known name. Example: Autoconf's ./configure script.