Question

I’m using gnu make, and gcc for compiling. I’m on linux (Ubuntu)

Here is a diagram for the game black jack where the nodes represent eventual object files.

---

I have organized the code where each class is in it’s own folder.

tree -d
.
└── classes
    ├── dealer
    │   └── hand
    ├── deck
    │   └── card
    │       ├── card_color
    │       ├── card_suit
    │       ├── card_value
    │       └── colorizer
    ├── discard_pile
    │   └── card
    ├── user
    │   └── hand
    │       └── card
    └── user_choice

In order to make the file-system behave like a graph, some directories are symbolic links.
There is no repeated code.
For example, if the actual card code is in the directory deck, then the hand and discard_pile folders have a symbolic link to that directory in them.

---

I have run into multiple definition errors, because my program links against all the sub directory object files.
It will follow symbolic links and end up gathering some object files more than once.
I can’t tell it to ignore symbolically linked folders, because sometimes they need to be followed.
For example: if I were to make a driver program in the dealer folder, it would need to gather the hand,card,card_color,card_suit,card_value,colorizer objects (even though the hand folder is a symbolic link).

---

Is there a way to continue gathering duplicate object files, but to tell gcc or make to ignore the duplicates before linking?
Because they are symbolic links, the path names are different.
Also, there may be instances where objects are named the same, but are different implementations.
I’m not sure how to identify that duplicate object files are indeed the same file and should not be linked more than once.

---

I don’t want to make this question too general by asking for advice on how to manage big and expanding projects (where entity relationships are complicated), but if you think my structure is nonsensical or problematic, please point out the problems and other ways you would go about it. I was trying to avoid having all my source files in one directory, because without class diagrams, the relationships would be difficult to derive.

Answer 1

Just becuse you USE the same function multiple times in different contexts doesn’t mean you need to link it more than once.

Your card.cpp needs to go into a common location that can be used by all your different components.

Typically, a project will have a set of header files, and a set of source files (.cpp or .c for example). When I work on small projects – less than about a dozen source files, I just keep all the files in one directory. But there’s nothing wrong with keeping it a bit more split up. However, a file should only be in one place in the directory structure [!!NO LINKS!!].

Header files are either with their respective source files, or in a separate “include” directory.

Typically, source files don’t “care” where the header files are, they are just “somewhere”. Instead you tell the compiler to look for headers in “../some-component” with -I ../some-component.

And each source file is only compiled and linked once, to form the final binary.